diff --git a/devcon-api/data/events/devcon-7.json b/devcon-api/data/events/devcon-7.json
index d9041f42..12e28e34 100644
--- a/devcon-api/data/events/devcon-7.json
+++ b/devcon-api/data/events/devcon-7.json
@@ -31,5 +31,5 @@
"main-stage",
"keynote"
],
- "version": "1731554176539"
+ "version": "1731555403257"
}
\ No newline at end of file
diff --git a/devcon-api/data/sessions/devcon-7/building-a-social-app-with-spend-permissions.json b/devcon-api/data/sessions/devcon-7/building-a-social-app-with-spend-permissions.json
index 311fd98f..0a356a84 100644
--- a/devcon-api/data/sessions/devcon-7/building-a-social-app-with-spend-permissions.json
+++ b/devcon-api/data/sessions/devcon-7/building-a-social-app-with-spend-permissions.json
@@ -36,7 +36,7 @@
"resources_presentation": "https://docs.google.com/presentation/d/1IMXFflR1DsQZPhVlnc9Ss-Xp6JJcahFgzp1FXWS8ldw",
"resources_slides": null,
"speakers": [
- "conner-swenberg",
- "lukas-rosario"
+ "lukas-rosario",
+ "conner-swenberg"
]
}
\ No newline at end of file
diff --git a/devcon-api/data/sessions/devcon-7/deep-dive-how-to-use-erc-3668-to-trustlessly-read-l2-data-from-l1.json b/devcon-api/data/sessions/devcon-7/deep-dive-how-to-use-erc-3668-to-trustlessly-read-l2-data-from-l1.json
index 8f2e23e5..da8d9d76 100644
--- a/devcon-api/data/sessions/devcon-7/deep-dive-how-to-use-erc-3668-to-trustlessly-read-l2-data-from-l1.json
+++ b/devcon-api/data/sessions/devcon-7/deep-dive-how-to-use-erc-3668-to-trustlessly-read-l2-data-from-l1.json
@@ -27,9 +27,9 @@
"resources_presentation": "https://docs.google.com/presentation/d/1W0jwOLdutdtpuJNo6WvxKfcV8v0h4mUvf0CLm68DfjQ",
"resources_slides": null,
"speakers": [
+ "julien",
"grant-southey",
"gregskrileth",
- "julien",
"thomas-clowes"
]
}
\ No newline at end of file
diff --git a/devcon-api/data/sessions/devcon-7/deva-awards.json b/devcon-api/data/sessions/devcon-7/deva-awards.json
new file mode 100644
index 00000000..9dafb9d4
--- /dev/null
+++ b/devcon-api/data/sessions/devcon-7/deva-awards.json
@@ -0,0 +1,21 @@
+{
+ "id": "deva-awards",
+ "sourceId": "KGA9ZA",
+ "title": "DEVA Awards",
+ "description": "The DEVA Awards at Devcon, are lighthearted accolades designed to celebrate and acknowledge outstanding contributions within the Ethereum ecosystem. These awards allow the community to express appreciation for projects and individuals who have significantly enhanced the utility and usability of Web3 technologies since the previous Devcon. It's important to note that the DEVA Awards are intended to be fun and not taken too seriously.",
+ "track": "Entertainment",
+ "type": "Talk",
+ "expertise": "",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [],
+ "tags": [],
+ "language": "en",
+ "speakers": [],
+ "eventId": "devcon-7",
+ "slot_start": 1731653700000,
+ "slot_end": 1731655200000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1kqglc9q5GnXKZpzbgqVtlSzsWyTWh7CppeW0EvBT9mc"
+}
\ No newline at end of file
diff --git a/devcon-api/data/sessions/devcon-7/epf-day-panel.json b/devcon-api/data/sessions/devcon-7/epf-day-panel.json
index 4dbdd63d..abe9695a 100644
--- a/devcon-api/data/sessions/devcon-7/epf-day-panel.json
+++ b/devcon-api/data/sessions/devcon-7/epf-day-panel.json
@@ -27,9 +27,9 @@
"resources_presentation": "https://docs.google.com/presentation/d/1zfYthY0BXd-oH251a-aAijUCaZpAylXrBQ0_5terdHk",
"resources_slides": null,
"speakers": [
- "echo",
- "eitan",
+ "mario-havel",
"eniko-nagy",
- "mario-havel"
+ "echo",
+ "eitan"
]
}
\ No newline at end of file
diff --git a/devcon-api/data/vectors/devcon-7.json b/devcon-api/data/vectors/devcon-7.json
index 93f1b9cf..47dd2800 100644
--- a/devcon-api/data/vectors/devcon-7.json
+++ b/devcon-api/data/vectors/devcon-7.json
@@ -794,9 +794,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
6,
6,
@@ -2714,9 +2711,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -3529,9 +3523,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
6,
6,
@@ -4904,9 +4895,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
6,
6,
@@ -5482,7 +5470,7 @@
"id": "a-fast-confirmation-rule-for-ethereum",
"sourceId": "F7RFTH",
"title": "A Fast Confirmation Rule for Ethereum",
- "description": "In this talk, we present an algorithm that, assuming good network conditions, reliably determines in less than a minute whether a proposed block will always be part of the canonical chain.\r\nThis represents a considerable speedup compared to waiting for the full security guarantees provided by block finalization, which takes 13 minutes in the best-case scenario.\r\nAlso, as we will explain, this algorithm provides a far better metric than chain depth, which some services still use.",
+ "description": "In this talk, we present an algorithm that, assuming good network conditions, reliably determines in less than a minute whether a proposed block will always be part of the canonical chain.\r\nThis represents a considerable speedup compared to waiting for the full security guarantees provided by block finalization, which takes 13 minutes in the best-case scenario.\r\nAlso, this algorithm provides a far better metric than chain depth, which some services still use. Paper https://arxiv.org/abs/2405.00549",
"track": "Core Protocol",
"type": "Talk",
"expertise": "Intermediate",
@@ -6269,9 +6257,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -7668,9 +7653,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
2,
@@ -9046,9 +9028,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
2,
@@ -10389,9 +10368,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -11792,9 +11768,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
2,
@@ -13166,9 +13139,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
2,
@@ -14539,9 +14509,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
2,
@@ -15889,9 +15856,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -17260,9 +17224,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -18665,9 +18626,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -20035,9 +19993,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -21391,9 +21346,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -22810,9 +22762,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
0,
@@ -24146,9 +24095,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -25484,9 +25430,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -26921,9 +26864,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
0,
@@ -28759,9 +28699,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -30115,9 +30052,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -31012,9 +30946,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
2,
@@ -32364,9 +32295,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -33692,9 +33620,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
6,
0,
@@ -35070,9 +34995,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -36523,9 +36445,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -37891,9 +37810,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
2,
@@ -39191,9 +39107,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -40565,9 +40478,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -41994,9 +41904,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -43314,9 +43221,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -44682,9 +44586,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -46044,9 +45945,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -47480,9 +47378,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -48767,9 +48662,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -50131,9 +50023,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -51489,9 +51378,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -52876,9 +52762,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -54240,9 +54123,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -55606,9 +55486,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -56985,9 +56862,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -58412,9 +58286,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -59838,9 +59709,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
2,
@@ -61103,9 +60971,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -62558,9 +62423,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
0,
@@ -64368,9 +64230,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -65182,9 +65041,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -65764,7 +65620,7 @@
"id": "blockchain-for-humanitarian-aid-disbursements",
"sourceId": "LTYZAJ",
"title": "Blockchain for humanitarian aid disbursements",
- "description": "This panel will discuss learnings from a UNICEF Nepal pilot using blockchain to create an efficient, transparent, and accountable aid distribution system. We’ll cover collaboration between UNICEF Nepal, Local Government and Rahat to develop and implement the technology for underbanked and unbanked communities. Additionally, we’ll explore expanding smart contract use in anticipatory action for preemptive climate disaster responses.",
+ "description": "We will share learnings from pilots in Nepal with a blockchain based platform, Rahat. We’ll cover collaboration between UNICEF Nepal and Local Government bodies to develop and implement the technology for underbanked and unbanked communities. Additionally, we’ll share how the learnings are shaping for more use cases with smart contracts for anticipatory action before the onset of a climate disaster and use of stablecoins for aid.",
"track": "Real World Ethereum",
"type": "Lightning Talk",
"expertise": "Beginner",
@@ -65792,8 +65648,7 @@
"language": "en",
"speakers": [
"rumee-singh",
- "arun-maharajan",
- "thakur-dhakal"
+ "arun-maharajan"
],
"eventId": "devcon-7",
"slot_start": 1731660000000,
@@ -65884,9 +65739,6 @@
0,
6,
6,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -67255,7 +67107,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -68002,8 +67853,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -68643,7 +68492,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -69316,8 +69164,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -70011,7 +69857,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -70679,8 +70524,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -71384,7 +71227,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -72054,8 +71896,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -72756,7 +72596,6 @@
0,
0,
0,
- 0,
6,
6,
0,
@@ -73439,8 +73278,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -74136,7 +73973,6 @@
0,
0,
0,
- 0,
6,
6,
6,
@@ -74907,8 +74743,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -75520,7 +75354,6 @@
0,
0,
0,
- 0,
6,
6,
6,
@@ -76248,8 +76081,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -76902,7 +76733,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -77563,8 +77393,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -78282,7 +78110,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -78942,8 +78769,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -79662,7 +79487,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -80311,8 +80135,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -81032,7 +80854,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -81700,8 +81521,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -82403,7 +82222,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -83060,8 +82878,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -83774,7 +83590,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -84427,8 +84242,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -85882,9 +85695,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -86513,7 +86323,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -87250,8 +87059,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -88620,9 +88427,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -89251,7 +89055,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -89994,8 +89797,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -91288,9 +91089,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -91999,7 +91797,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -92741,8 +92538,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -93375,7 +93170,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -94037,8 +93831,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -94744,7 +94536,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -95400,8 +95191,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -95967,7 +95756,7 @@
"id": "building-a-builder-community-in-africa-from-ground-up-the-hurdles-to-navigate-the-silo-mindset-and-overcoming-it-with-clear-conviction",
"sourceId": "XZ7E7A",
"title": "Building a builder community in Africa from ground up: The hurdles to navigate, the silo mindset and overcoming it with clear conviction.",
- "description": "Zuzalu and Zuconnect both experiences changed our approach towards Ethereum. We took pragmatic steps by coordinating with different communities towards creating a viable builder network in Africa. 1. We engaged web3brige to be a Hackathon partner and we put together biggest Hackathon with real project built and some with trackable results .2. Initiatives such as EthAbuja and EthJos to spread the builder base beyond Lagos. 3. Got muAccra happened first its in Africa with over 100 builders.",
+ "description": "Join us to explore the growing African tech talent pool. We'll discuss how initiatives like AyaHQ, web3bridge, and web3clubs have empowered developers through education, hackathons, residency programs etc. Learn about the impact of their work, the challenges they face, and how these initiatives—among others—are helping shape the future of Ethereum in Africa.",
"track": "Real World Ethereum",
"type": "Panel",
"expertise": "Beginner",
@@ -96117,7 +95906,6 @@
0,
0,
0,
- 0,
6,
6,
6,
@@ -96757,8 +96545,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -97490,7 +97276,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -98175,8 +97960,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -98870,7 +98653,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -99529,8 +99311,6 @@
0,
0,
0,
- 0,
- 0,
2,
2,
0,
@@ -100251,7 +100031,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -100945,8 +100724,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -101622,7 +101399,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -102249,8 +102025,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -102844,7 +102618,6 @@
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
"tags": [
"Use Cases",
"Social",
@@ -102855,16 +102628,26 @@
"Social",
"Use Cases"
],
+ "keywords": [],
+ "duration": 2355,
"language": "en",
- "speakers": [
- "lukas-rosario",
- "conner-swenberg"
- ],
+ "sources_swarmHash": "",
+ "sources_youtubeId": "9daSgrLWIgY",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": "67347f6a9dbb7a90e1b460fc",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67347f6a9dbb7a90e1b460fc.vtt",
+ "transcript_text": " Hello, welcome. Thank you for coming by. This is Lucas and I'm Connor and we're here from the base team, the smart wallet specifically. And we're here to talk about this new feature we're launching soon called Spend Permissions. So Spend Permissions, that title got messed up, sorry. Spend Permissions allow you to create one click or no click experiences that can spend users' tokens. This is important because we all want better UX within Web 3.0. It's kind of annoying to have pop-ups all the time when you're doing a transaction. And so with spend permissions, you're able to give permission to an app to spend your tokens so that the app can do fancy transactions to pull your assets and then do fun things with them. And this workshop is going to show you one of those things is a social app. And so today we're going to talk about how it works for a brief few minutes, talk about a roadmap when we're launching this and when you can get started building. And then we're going to talk about some fundamentals. This is where the workshop actually begins. We'll be doing some live coding, and you can fork our starter repo, and then we'll also be finishing with an NFT micropayment use case at the very end. So for those of you not familiar with Smart Wallet, it is a smart contract account that has self-custodial passkeys. This means that users can easily onboard if they have a device that supports passkeys, which is most people in this room. You can scan with Face ID if you have iOS or thumbprints if you have your computer or your phone with a thumbprint scanner. With Smart Wallet you can also sponsor gas for transactions so users can convert easier and not have to fill up their wallet to get started. And you can also batch transactions to make it easier for people to do things with less steps. But one of the problems we've encountered with Smart Wallet and all wallets in general is that there's still too much friction to transact. People really are addicted to one-click experiences like we have in WebTube. So there are two ways that we've actually explored doing these one-click experiences. And Session Keys is where we actually started. And it's this idea that you can give permissions to apps to transact other contracts. And it's incredibly flexible, but after exploring this deeper, we realized that this actually has some security discomfort for us, and we don't want to let apps call random contracts on our behalf. Even if we inform the user what's being called and what functions, we just don't believe that users are informed enough to give approval to those kinds of permissions. And so that's what brought us to spend permissions. It's a way of tightening the scope of what we allow apps to do on behalf of our accounts, and it's focused only on spending assets. We think that spending assets is actually the majority of reasons apps need to interact with accounts. And after an app has assets from the user, it can then do things like mint NFTs, swap tokens, staking on DeFi, whatever you need. And in this sense, we actually feel way more confident with the security posture of spend-only permissions, and you can still solve the majority of the things we care about. So what are the use cases we think people want to build with? The first, which we'll demo today, is microtransactions. These are high-frequency interactions that you'll want users on your app. Because they're high-fre frequency, it's naturally very annoying if you have a pop-up every single time. And so use cases like this in social would be a Zora app, where it's basically Instagram, but instead of liking you're collecting NFTs, you may be liking all the time. Other microtransaction examples would be gaming, very high frequency. People want to go through many operations for a game potentially and do it quickly. And so before, you would have a pop-up every time, but now you can just give permission once to spend some ETH or an ERC20 and then whenever you click a button or do something in the background, it's just going and transacting without you noticing. The second use case we're really excited about is subscriptions. This is an example of a pattern where users don't have to be on the app anymore. This is where permissions really shine and you can do things uniquely that we couldn't do before with wallets. And so in a subscription case, you will give your app permission to spend your tokens on some recurring basis. And then even when you're outside the app, it'll just pull money from your wallet, no pressure needed. And so in this case, subscriptions are not the only background process you need to do. Other background operations could be automated trading, copy trading. Things that are more DeFi native also shine very nicely with background transactions. But these are the two that we think are most relevant immediately. So how does this actually work? So this is a sample diagram of what on-chain looks like. And typically a smart wallet, we think of having one or a few PASC owners. And so you can see the smart wallet contract in the bottom left. It has an owner relationship to a PASCII and we typically reference that PASCII by its public key so 64 bytes. Smart wallet also supports owners that can be Ethereum addresses which includes smart contracts and so for the spend permission system we're actually adding a new contract as an owner to smart wallets called the permission manager and through this ownership system we're able to delegate other permissions to spenders. And so you can see the spender relationship between our permission manager and a spender entity, which is itself another Ethereum address. And so once you have this ownership relationship set up, the flow of a transaction looks a bit different than normal. So originally, transactions for session keys originate from the smart wallet account, but this time a spender is calling through the permission manager to spend some tokens. And then the permission manager being an owner is able to call execute on the smart wallet to get it to call anything it wants. In this case, we want to call the smart wallet to transfer some value, and in this case, back to the spender. And so so yeah. And so how do you actually use this off-chain? The first thing we need to do is approve a permission from the user. We do this with ETH sign type data. It's using EIP 712 signatures. We chose this path because it's the easiest way to ask the user for a signature of structured data. Before we were working on a standard called ERC 7715, we felt that 712 was actually an easier place to start, but we're still open to working with 7715 in the future. But the user sees a very simple approval here, where the app is just asking them to allow to spend some currency on a recurring basis. In this case, 10 USDC every month could be a very simple subscription experience. And we also have a start and end time. So in most cases, you'll want the start time to be right now and the expiry to be sometime in the future. The apps we've been talking to typically want the expiry to actually be infinite, which is something we think is interesting, where users would have to revoke if they ever want to remove the permission. But that's up to every app to decide for themselves. After the user has approved a permission and then therefore signed it with their passkey, the signature is given back to the app. And now the app can use that signature to apply it as an approval on chain. And that's that first optional call in the top. After a spender has approved the permission with the signature from the user, it's able to spend. And so then that's number two on this diagram where the spender is calling into the permission manager to use the permission. The permission manager will then validate it, call execute on the smart wallet. And depending on if you're using native token or ERC-20 token, the smart wallet will either call directly back to the spender to transfer ETH, or call the ERC-20 contract with the transfer function to send the tokens. The third piece here is revoking. It's very important that users are always able to revoke permissions after they've approved them. This is fortunately a way we can actually differentiate from TradFi and the existing world because it's very frustrating that you can subscribe to an app but not easily unsubscribe. A lot of apps make it very difficult, but we believe that in the new world, users should always have control of their assets and have control over their permissions. So permission management is always",
"eventId": "devcon-7",
"slot_start": 1731490200000,
"slot_end": 1731495600000,
"slot_roomId": "classroom-c",
- "resources_presentation": "https://docs.google.com/presentation/d/1IMXFflR1DsQZPhVlnc9Ss-Xp6JJcahFgzp1FXWS8ldw"
+ "resources_presentation": "https://docs.google.com/presentation/d/1IMXFflR1DsQZPhVlnc9Ss-Xp6JJcahFgzp1FXWS8ldw",
+ "resources_slides": null,
+ "speakers": [
+ "conner-swenberg",
+ "lukas-rosario"
+ ]
},
"vector": [
0,
@@ -102991,7 +102774,6 @@
0,
0,
0,
- 0,
6,
6,
0,
@@ -103668,8 +103450,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -104364,7 +104144,6 @@
0,
0,
0,
- 0,
6,
6,
6,
@@ -105001,8 +104780,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -105724,7 +105501,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -106373,8 +106149,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -107121,7 +106895,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -107768,8 +107541,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -108493,7 +108264,6 @@
0,
0,
0,
- 0,
6,
6,
0,
@@ -109166,8 +108936,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -109869,7 +109637,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -110583,8 +110350,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -111250,7 +111015,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -111878,8 +111642,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -112614,7 +112376,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -113255,8 +113016,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -113981,7 +113740,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -114612,8 +114370,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -115346,7 +115102,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -116016,8 +115771,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -116717,7 +116470,6 @@
0,
0,
0,
- 0,
6,
6,
6,
@@ -117451,8 +117203,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -118095,7 +117845,6 @@
0,
0,
0,
- 0,
6,
6,
6,
@@ -118730,8 +118479,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -119467,7 +119214,6 @@
0,
0,
0,
- 0,
6,
6,
0,
@@ -120169,8 +119915,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -120839,7 +120583,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -121444,8 +121187,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -122208,7 +121949,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -122821,8 +122561,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -123571,7 +123309,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -124180,8 +123917,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -124937,7 +124672,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -125578,8 +125312,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -126309,7 +126041,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -126905,8 +126636,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -127679,7 +127408,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -128285,8 +128013,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
6,
@@ -129051,7 +128777,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -129655,8 +129380,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -130422,7 +130145,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -131029,8 +130751,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -131793,7 +131513,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -132442,8 +132161,6 @@
0,
0,
0,
- 0,
- 0,
2,
2,
0,
@@ -133164,7 +132881,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -133808,8 +133524,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -134470,7 +134184,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -135163,8 +134876,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -135923,7 +135634,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -136532,8 +136242,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -137296,7 +137004,6 @@
0,
0,
0,
- 0,
6,
6,
6,
@@ -137902,8 +137609,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -138671,7 +138376,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -139283,8 +138987,6 @@
0,
0,
0,
- 0,
- 0,
2,
2,
0,
@@ -140045,7 +139747,6 @@
0,
0,
0,
- 0,
6,
6,
6,
@@ -140647,8 +140348,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -142543,9 +142242,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -142768,7 +142464,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -143365,8 +143060,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -144142,7 +143835,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -144827,8 +144519,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -145513,7 +145203,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -146100,8 +145789,6 @@
0,
0,
0,
- 0,
- 0,
6,
6,
0,
@@ -146883,7 +146570,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -147558,8 +147244,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -148256,7 +147940,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -148829,8 +148512,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -149621,7 +149302,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -150206,8 +149886,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -150984,7 +150662,6 @@
0,
0,
0,
- 0,
6,
6,
6,
@@ -152117,8 +151794,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -152351,7 +152026,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -152919,8 +152593,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -153717,7 +153389,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -154284,8 +153955,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -155057,7 +154726,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -155663,8 +155331,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -156444,7 +156110,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -157059,8 +156724,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -158586,9 +158249,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
2,
0,
@@ -159160,7 +158820,6 @@
0,
0,
0,
- 0,
6,
6,
0,
@@ -160291,8 +159950,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -160545,7 +160202,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -161139,8 +160795,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -161910,7 +161564,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -162503,8 +162156,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -163279,7 +162930,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -163845,8 +163495,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -164650,7 +164298,6 @@
0,
0,
0,
- 0,
6,
6,
0,
@@ -165214,8 +164861,6 @@
0,
0,
0,
- 0,
- 0,
6,
6,
0,
@@ -166025,7 +165670,6 @@
0,
0,
0,
- 0,
6,
6,
0,
@@ -166615,8 +166259,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -167165,40 +166807,55 @@
},
{
"session": {
- "id": "coordination-accelerationism-a-manifesto",
- "sourceId": "NGXHAA",
- "title": "Coordination Accelerationism: A Manifesto",
- "description": "In this talk, we place crypto in the context of evolutionary timescale. We present an overview of the various types of coordination systems, their advantages and weaknesses. The most robust type of coordination mechanism is something we term as, self-enforcing coordination systems (SECS) - which do not require an authority, a committee or even a majority of entities to enforce the conditions of coordination. We also show how to build the most general form of SECS.",
- "track": "Coordination",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "id": "copying-memory-in-evm-how-hard-can-that-be",
+ "sourceId": "JKFBN3",
+ "title": "Copying Memory in EVM, how hard can that be?",
+ "description": "Memory copy operations in EVM are a useful feature, but there are different ways to do. How do they differ? Which is the best?\r\nThe options are:\r\nMLOAD+MSTORE loop\r\nIdentity Precompile\r\nThe new MCOPY opcode\r\nBased on concrete examples we will explain how these options differ. We will use different examples as the amount of bytes copied makes a difference. For all these options we will present gas consumption and code size.\r\nThis way we can compare the different options to copy memory and crown the ult",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Forking"
- ],
"tags": [
- "fork",
- "Collective Intelligence",
- "Consensus",
- "Coordination"
+ "Core Protocol",
+ "Gas",
+ "Developer Infrastructure",
+ "compilers",
+ "optimised",
+ "Core Protocol",
+ "Developer Infrastructure",
+ "Gas"
],
- "language": "en",
- "speakers": [
- "robert-drost"
+ "keywords": [
+ "Optimisations",
+ "Compilers"
],
+ "duration": 495,
+ "language": "en",
+ "sources_swarmHash": "cfc406c95e513fab06ed3c115ed870f47b7edc58852cfbb26268ceb00350b80d",
+ "sources_youtubeId": "en-Oeie6ZEs",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343c129dbb7a90e1a51151.vtt",
+ "transcript_text": " Hi everyone, am I audible? Good to see you. I'm Elian Suoni, I also work at Chain Security. I can guarantee this was not on purpose. We didn't bribe the organizers. It was so nice of them. My topic for today is arguably the best fit for a lightning talk, because it turns out it's not that hard to copy in the VM, especially since Cancun. But yeah, we'll see exactly how much. So yeah, the right way to think about it, in my opinion, is before Cancun and after Cancun. Because since Cancun, we have a new opcode that does exactly that. And it's arguably the best way to do it. But before then, you had to implement this some other way. And there were two main ways to do that, to copy from memory to memory in the EVM. So one was to do an M load plus M store loop. So you would do 32 bytes at a time. You would load 32 bytes from memory onto the stack and store them back from the stack to the destination in memory. And this used to be, well, quite heavy in terms of code size because it's a full loop. And it also had quite a bad gas cost in terms of gas cost per memory word copied. The alternative was calling the identity recompile that we just saw with the last presentation, and while that has a little less code size because it's just a static call that you can do to the contract, still the gas per memory word is good enough. It's only three gas per memory word that you copy. But the overhead is quite big because you have to do a call. So it's at least, I think it's 180. Yeah, we'll see later. Anyway, since Cancun, all our problems are solved because we have a new opcode that does exactly that. It has the least code size because because it's just one off code, the least amount of gas. So now there's no reason not to use it. And as I'll tell you, it's very much widespread now. So let's just go quickly over some numbers. One way to implement the emload and store loop is in software. This is done in a quite popular, yet a bit old, Solidity library. And because it's done in high-level Solidity rather than entirely in assembly, then you see you have two checked additions, a checked subtraction, all this done for every memory word that you copy, which adds up to a gas cost of around 286 gas per memory word copied, which is quite bad. Then we have the same concept implemented entirely in assembly, which is what the Solidity compiler will auto-generate for you. It's a function. If you inspect the IR, it's called copy memory to memory with cleanup, I think. And yeah, it's a tighter loop, so it has less overhead. So overall, the cost per memory word copied is only 67, yeah, 67 gas. And the code size is also much smaller. Then just to see an example of how the identity recompile would be used, it's used by C4 library. And also it's what Vypr used to generate to copy memory to memory before Cancun. And yeah, the cost per word is the best. It's just three words, three gas. But the overhead, the constant term, as you can see, is quite big because you have to make a static call that has also a fixed cost of 15 inside, and then you have to do some checks. So it's not ideal for small copies. Now, keep in mind that we're neglecting the memory expansion cost, because that'll be the same whichever method you opt for. And also, we're doing this comparison right now with these opcode pricing, but keep in mind that those have changed and will change again in the future. So whatever conclusion on which method might be the most convenient now maybe wasn't the same. You wouldn't have come to the same conclusion five years ago, for example. But yeah, just to be sure about it, now the mcopy opcode is used by both Solidity and Viper for Cancun contracts, and the gas cost is the least, the code size is the least, so everything is good, the future is bright. I didn't have the time to add the slides to this, but from the same analysis that Dominic and the other colleagues at TuneSecurity did, it turns out that already now the mcopy opcode is already used more than the identity precompile, even though it's only quite new since Cancun. So it shows that, I mean, I don't know exactly how to phrase it. Maybe there's a lot of new contracts deployed that already outnumber the number of, I guess, Solidity Viber contracts for legacy. So, yeah, it's quite popular already. Then, yeah, I've prepared a remix setup for you. And also, if you want to shoot a message to our sales representatives to get an audit, which is never a bad idea, feel free to do so. Yeah, I'll take any questions. Thank you for the session. Please do you have questions? Oh, wow. You have a lot today. I'll try. Hello. Hello. You said that the memory expansion cost is the same in all three cases. Yeah. But my concern is that with the loop option, if the memory you are copying is not a multiple of 32, not only you may copy memory you don't need to copy, so that's more expansion, but also you may override something that is outside of your destination, like just after your destination. Yeah, so the memory expansion cost is actually I'm only 87% sure about this, but it's only computed on the number of memory words rounded up. So even if you end up writing at most 31 bytes, you don't incur memory expansion cost for another word. So it is the same, even if you overwrite within the same word that you've already paid for. Then, what was your other question? Ah, for overlapping, yeah. If in some of those functions are specified for cases where the overlap is okay, for example in the Yule one, because I think that one is only used to allocate at the tip of the memory so there's nothing afterwards. But in cases where that's not okay, for example the library, they do special tricks, like they round it up with an m store that's aligned to the last byte that you want to write to, and the rest, they mask it with the content that's already there. So you're basically writing back what's already there on the part that overlaps, and just on the new part, say the 20 bytes you'll write the new stuff. One more question for Elias. Okay no question. I'm curious Elias, so as a non-technical person, being almost everybody's a technical here, How do you communicate to a novice like me to be able to comprehend in simple language? Huh. I think I have a knack for it. It just comes natural to me. For me, I don't think I've understood something until I can explain it to my mom. So I guess... Thank you so much, guys. For me, I don't think I've understood something until I can explain it to my mom. So I guess that's it. Thank you so much, guys. Let's give him a hand of applause. Wow.",
"eventId": "devcon-7",
- "slot_start": 1731558600000,
- "slot_end": 1731560400000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1pAUfWWkDdvSVfjG3UFm9ChrQDu1XE0Ae1vmkkLNxV3A"
+ "slot_start": 1731471600000,
+ "slot_end": 1731472200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1zHvG3U1k7Ixpod7JNDZSJechFPRUfpGmYtaC0t0ufJA",
+ "resources_slides": null,
+ "speakers": [
+ "elia-anzuoni"
+ ]
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -167206,8 +166863,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -167952,10 +167607,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -167968,6 +167619,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -167981,7 +167633,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -168003,6 +167654,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -168102,7 +167754,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -168176,6 +167827,8 @@
0,
2,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -168508,11 +168161,10 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
@@ -168523,6 +168175,7 @@
0,
0,
0,
+ 2,
0,
0,
0
@@ -168530,57 +168183,43 @@
},
{
"session": {
- "id": "copying-memory-in-evm-how-hard-can-that-be",
- "sourceId": "JKFBN3",
- "title": "Copying Memory in EVM, how hard can that be?",
- "description": "Memory copy operations in EVM are a useful feature, but there are different ways to do. How do they differ? Which is the best?\r\nThe options are:\r\nMLOAD+MSTORE loop\r\nIdentity Precompile\r\nThe new MCOPY opcode\r\nBased on concrete examples we will explain how these options differ. We will use different examples as the amount of bytes copied makes a difference. For all these options we will present gas consumption and code size.\r\nThis way we can compare the different options to copy memory and crown the ult",
- "track": "Core Protocol",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "",
+ "id": "corruption-kyc-and-the-cost-of-compliance",
+ "sourceId": "8FQ3HT",
+ "title": "Corruption, KYC and the Cost of Compliance",
+ "description": "Trillions of dollars in illicit financial flows slosh around our financial system today, facilitated by the most powerful centralised instiutitons. Current efforts to address IFFs are ineffective and result in harmful side effects for some of the most vulnernable in society. In this article, we investigate the causes and impact of IFFs. Despite what certain bankers and politicians might have told you, the transparency and programmability of cryptocurrencies are a solution to, not a cause of, the",
+ "track": "Cypherpunk & Privacy",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Core Protocol",
- "Gas",
- "Developer Infrastructure",
- "compilers",
- "optimised",
- "Core Protocol",
- "Developer Infrastructure",
- "Gas"
- ],
"keywords": [
- "Optimisations",
- "Compilers"
+ "Compliance",
+ "Illicit Financial Flows",
+ "KYC/AML"
+ ],
+ "tags": [
+ "Anonymity",
+ "Censorship Resistance",
+ "Civil Resistance"
],
- "duration": 495,
"language": "en",
- "sources_swarmHash": "cfc406c95e513fab06ed3c115ed870f47b7edc58852cfbb26268ceb00350b80d",
- "sources_youtubeId": "en-Oeie6ZEs",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343c129dbb7a90e1a51151.vtt",
- "transcript_text": " Hi everyone, am I audible? Good to see you. I'm Elian Suoni, I also work at Chain Security. I can guarantee this was not on purpose. We didn't bribe the organizers. It was so nice of them. My topic for today is arguably the best fit for a lightning talk, because it turns out it's not that hard to copy in the VM, especially since Cancun. But yeah, we'll see exactly how much. So yeah, the right way to think about it, in my opinion, is before Cancun and after Cancun. Because since Cancun, we have a new opcode that does exactly that. And it's arguably the best way to do it. But before then, you had to implement this some other way. And there were two main ways to do that, to copy from memory to memory in the EVM. So one was to do an M load plus M store loop. So you would do 32 bytes at a time. You would load 32 bytes from memory onto the stack and store them back from the stack to the destination in memory. And this used to be, well, quite heavy in terms of code size because it's a full loop. And it also had quite a bad gas cost in terms of gas cost per memory word copied. The alternative was calling the identity recompile that we just saw with the last presentation, and while that has a little less code size because it's just a static call that you can do to the contract, still the gas per memory word is good enough. It's only three gas per memory word that you copy. But the overhead is quite big because you have to do a call. So it's at least, I think it's 180. Yeah, we'll see later. Anyway, since Cancun, all our problems are solved because we have a new opcode that does exactly that. It has the least code size because because it's just one off code, the least amount of gas. So now there's no reason not to use it. And as I'll tell you, it's very much widespread now. So let's just go quickly over some numbers. One way to implement the emload and store loop is in software. This is done in a quite popular, yet a bit old, Solidity library. And because it's done in high-level Solidity rather than entirely in assembly, then you see you have two checked additions, a checked subtraction, all this done for every memory word that you copy, which adds up to a gas cost of around 286 gas per memory word copied, which is quite bad. Then we have the same concept implemented entirely in assembly, which is what the Solidity compiler will auto-generate for you. It's a function. If you inspect the IR, it's called copy memory to memory with cleanup, I think. And yeah, it's a tighter loop, so it has less overhead. So overall, the cost per memory word copied is only 67, yeah, 67 gas. And the code size is also much smaller. Then just to see an example of how the identity recompile would be used, it's used by C4 library. And also it's what Vypr used to generate to copy memory to memory before Cancun. And yeah, the cost per word is the best. It's just three words, three gas. But the overhead, the constant term, as you can see, is quite big because you have to make a static call that has also a fixed cost of 15 inside, and then you have to do some checks. So it's not ideal for small copies. Now, keep in mind that we're neglecting the memory expansion cost, because that'll be the same whichever method you opt for. And also, we're doing this comparison right now with these opcode pricing, but keep in mind that those have changed and will change again in the future. So whatever conclusion on which method might be the most convenient now maybe wasn't the same. You wouldn't have come to the same conclusion five years ago, for example. But yeah, just to be sure about it, now the mcopy opcode is used by both Solidity and Viper for Cancun contracts, and the gas cost is the least, the code size is the least, so everything is good, the future is bright. I didn't have the time to add the slides to this, but from the same analysis that Dominic and the other colleagues at TuneSecurity did, it turns out that already now the mcopy opcode is already used more than the identity precompile, even though it's only quite new since Cancun. So it shows that, I mean, I don't know exactly how to phrase it. Maybe there's a lot of new contracts deployed that already outnumber the number of, I guess, Solidity Viber contracts for legacy. So, yeah, it's quite popular already. Then, yeah, I've prepared a remix setup for you. And also, if you want to shoot a message to our sales representatives to get an audit, which is never a bad idea, feel free to do so. Yeah, I'll take any questions. Thank you for the session. Please do you have questions? Oh, wow. You have a lot today. I'll try. Hello. Hello. You said that the memory expansion cost is the same in all three cases. Yeah. But my concern is that with the loop option, if the memory you are copying is not a multiple of 32, not only you may copy memory you don't need to copy, so that's more expansion, but also you may override something that is outside of your destination, like just after your destination. Yeah, so the memory expansion cost is actually I'm only 87% sure about this, but it's only computed on the number of memory words rounded up. So even if you end up writing at most 31 bytes, you don't incur memory expansion cost for another word. So it is the same, even if you overwrite within the same word that you've already paid for. Then, what was your other question? Ah, for overlapping, yeah. If in some of those functions are specified for cases where the overlap is okay, for example in the Yule one, because I think that one is only used to allocate at the tip of the memory so there's nothing afterwards. But in cases where that's not okay, for example the library, they do special tricks, like they round it up with an m store that's aligned to the last byte that you want to write to, and the rest, they mask it with the content that's already there. So you're basically writing back what's already there on the part that overlaps, and just on the new part, say the 20 bytes you'll write the new stuff. One more question for Elias. Okay no question. I'm curious Elias, so as a non-technical person, being almost everybody's a technical here, How do you communicate to a novice like me to be able to comprehend in simple language? Huh. I think I have a knack for it. It just comes natural to me. For me, I don't think I've understood something until I can explain it to my mom. So I guess... Thank you so much, guys. For me, I don't think I've understood something until I can explain it to my mom. So I guess that's it. Thank you so much, guys. Let's give him a hand of applause. Wow.",
- "eventId": "devcon-7",
- "slot_start": 1731471600000,
- "slot_end": 1731472200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1zHvG3U1k7Ixpod7JNDZSJechFPRUfpGmYtaC0t0ufJA",
- "resources_slides": null,
"speakers": [
- "elia-anzuoni"
- ]
+ "jarrad-hope"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731582000000,
+ "slot_end": 1731583800000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1YTeRCkNqi_tWXXuL2gLaihLcpRslx1hjlAncemiP4bU"
},
"vector": [
0,
0,
0,
0,
- 6,
- 0,
0,
+ 6,
0,
0,
0,
@@ -169345,12 +168984,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -169380,7 +169019,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -169473,6 +169111,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -169551,11 +169190,9 @@
0,
0,
0,
- 2,
0,
0,
2,
- 2,
0,
0,
0,
@@ -169887,10 +169524,11 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
+ 2,
0,
0,
0,
@@ -169901,7 +169539,6 @@
0,
0,
0,
- 2,
0,
0,
0
@@ -169909,35 +169546,41 @@
},
{
"session": {
- "id": "corruption-kyc-and-the-cost-of-compliance",
- "sourceId": "8FQ3HT",
- "title": "Corruption, KYC and the Cost of Compliance",
- "description": "Trillions of dollars in illicit financial flows slosh around our financial system today, facilitated by the most powerful centralised instiutitons. Current efforts to address IFFs are ineffective and result in harmful side effects for some of the most vulnernable in society. In this article, we investigate the causes and impact of IFFs. Despite what certain bankers and politicians might have told you, the transparency and programmability of cryptocurrencies are a solution to, not a cause of, the",
- "track": "Cypherpunk & Privacy",
+ "id": "cross-l2-with-intent-addresses",
+ "sourceId": "BEWE3Q",
+ "title": "Cross L2 with Intent Addresses",
+ "description": "Ethereum today is more fragmented than ever before. We'll talk about how CREATE2 intent addresses and ERC-4337 can be used to enable fast and smooth cross-chain interactions for consumer applications.",
+ "track": "Usability",
"type": "Talk",
- "expertise": "Beginner",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Compliance",
- "Illicit Financial Flows",
- "KYC/AML"
+ "CCTP",
+ "bridging",
+ "chain-abstraction"
],
"tags": [
- "Anonymity",
- "Censorship Resistance",
- "Civil Resistance"
+ "Architecture",
+ "Cross-L2",
+ "Account Abstraction",
+ "chain",
+ "abstraction",
+ "Account Abstraction",
+ "Architecture",
+ "Cross-L2"
],
"language": "en",
"speakers": [
- "jarrad-hope"
+ "nalin-b",
+ "dc-posch"
],
"eventId": "devcon-7",
- "slot_start": 1731582000000,
- "slot_end": 1731583800000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1YTeRCkNqi_tWXXuL2gLaihLcpRslx1hjlAncemiP4bU"
+ "slot_start": 1731574800000,
+ "slot_end": 1731576600000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/19NEsXDqwrsMeZ3hvkerJHBNN4pTD7oRWn6fSazU8JWU"
},
"vector": [
0,
@@ -169945,12 +169588,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -170086,6 +169727,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -170718,10 +170360,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -170745,6 +170383,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -170755,6 +170394,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -170840,7 +170480,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -170893,6 +170532,9 @@
0,
0,
0,
+ 2,
+ 2,
+ 2,
0,
0,
0,
@@ -170922,7 +170564,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -171252,13 +170893,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
2,
0,
- 2,
- 0,
0,
0,
0,
@@ -171275,44 +170915,39 @@
},
{
"session": {
- "id": "cross-l2-with-intent-addresses",
- "sourceId": "BEWE3Q",
- "title": "Cross L2 with Intent Addresses",
- "description": "Ethereum today is more fragmented than ever before. We'll talk about how CREATE2 intent addresses and ERC-4337 can be used to enable fast and smooth cross-chain interactions for consumer applications.",
- "track": "Usability",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "crypto-in-action-powering-ukraines-resilience",
+ "sourceId": "7JZGQJ",
+ "title": "Crypto in Action: Powering Ukraine's Resilience",
+ "description": "Discover the critical role of crypto in supporting Ukraine's recovery amidst ongoing challenges. We will highlight real-world examples in energy, housing, food distribution, communication, and more, showcasing its tangible impact.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "CCTP",
- "bridging",
- "chain-abstraction"
+ "Resilient infrastructure",
+ "Ukraine",
+ "crypto donations"
],
"tags": [
- "Architecture",
- "Cross-L2",
- "Account Abstraction",
- "chain",
- "abstraction",
- "Account Abstraction",
- "Architecture",
- "Cross-L2"
+ "Civil Resistance",
+ "Coordination",
+ "Public good"
],
"language": "en",
"speakers": [
- "nalin-b",
- "dc-posch"
+ "rev-miller"
],
"eventId": "devcon-7",
- "slot_start": 1731574800000,
- "slot_end": 1731576600000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/19NEsXDqwrsMeZ3hvkerJHBNN4pTD7oRWn6fSazU8JWU"
+ "slot_start": 1731582000000,
+ "slot_end": 1731582600000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/19vJbc3_xafMXjoRH6SLUAgIZjg0J4oTsoiFzXzdq3Ao"
},
"vector": [
0,
+ 6,
0,
0,
0,
@@ -171320,7 +170955,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -171457,7 +171091,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -172115,8 +171748,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -172126,7 +171757,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -172174,6 +171804,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -172219,6 +171850,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -172264,9 +171896,6 @@
0,
0,
0,
- 2,
- 2,
- 2,
0,
0,
0,
@@ -172295,6 +171924,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -172625,7 +172255,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -172636,6 +172265,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -172647,45 +172278,57 @@
},
{
"session": {
- "id": "crypto-in-action-powering-ukraines-resilience",
- "sourceId": "7JZGQJ",
- "title": "Crypto in Action: Powering Ukraine's Resilience",
- "description": "Discover the critical role of crypto in supporting Ukraine's recovery amidst ongoing challenges. We will highlight real-world examples in energy, housing, food distribution, communication, and more, showcasing its tangible impact.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "crypto-is-the-real-world-understanding-the-cryptonative-economy",
+ "sourceId": "UCZ83J",
+ "title": "Crypto is the Real World: Understanding the Cryptonative Economy",
+ "description": "Ethereum has often been viewed as a separate, speculative space detached from the \"real world.\" However, recent developments and analyses reveal that the cryptonative economy is not only substantial but also comparable to traditional economies in its scope and dynamics. This talk will delve into the findings of the Cryptonative Economy Reports, highlighting the significant economic demand for Ethereum and showcasing where has Ethereum become the real world already.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Resilient infrastructure",
- "Ukraine",
- "crypto donations"
- ],
"tags": [
- "Civil Resistance",
- "Coordination",
- "Public good"
+ "Digital Sovereignty",
+ "Use Cases",
+ "Economics",
+ "cryptonative",
+ "Digital Sovereignty",
+ "Economics",
+ "Use Cases"
],
- "language": "en",
- "speakers": [
- "rev-miller"
+ "keywords": [
+ "Real world",
+ "Ecosystem",
+ "Cryptonativism"
],
+ "duration": 991,
+ "language": "en",
+ "sources_swarmHash": "9a3b05187a79c6bb70f1acb84dcc9c89cdbac55482d6f2a8c022454a40a42a1c",
+ "sources_youtubeId": "Y0u6J1OmPXc",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f3dccacabd9035b773c0.vtt",
+ "transcript_text": " Hey everybody. So crypto is the real world. Today I'm going to try to convince you that crypto isn't a niche anymore, but that in fact it's a blueprint to the future of economy. And one thing that triggered me to pick this topic is that, like, increasingly we started using the term RWAs, the real world assets, which kind of implies that, well, all of the other stuff that we've been using so far isn't the real world. And I actually would like to protest today and make a case about this actually not being the reality. So my name is Joseph. I got into crypto in 2011 thanks to Socroat. Then thanks to Ethereum, I started organizing meetups and started getting my hands dirty. I used to work as a Solidity Dev and Auditor. And then since 2018, I helped the Ethereum Foundation with organizing operations around the R&D teams. And finally, since the beginning of 2022, I started Pondow and started hosting conferences on my own. As mentioned, I used to help with DEF CONs before, so I'm thrilled to see how they've grown. And well, thanks to the team organizing this. I know you can't see the talks, but maybe later this will make you happy. I'll take you to several steps first I'll look at into the terminology what is an economy or what is the crypto native economy and how does it compare to the real world and finally I'll finish out with a quick retrospect of the past few years so what is an economy I'll borrow a definition from the Austrian economics of basically two long-distance reads from Mises and Hayek. An economy is the result of individual actions and choices driven by human purpose and subjective preferences. It is a network of voluntary exchanges and cooperative activities where resources are allocated through the spontaneous interactions of individuals in the market. So we could say it's it's a living organism and here during the talk I'll try to try to describe that living organism very imperfectly because it's very hard to give you the up-to-date numbers so what you see here what you what you're going to see are basically best attempts and estimates and therefore would like to ask you to challenge those numbers and later on reach out or publish articles on your own trying to get those numbers right. Because that's the only way we can actually describe the reality in the best way. So what is the crypto-native economy? With Pond, we've been publishing these crypto-native economy reports for the past several years. And what we attempt is to look into the on-chain revenue. So all of the stuff that happens on-chain as a measurement of that economic interaction, of the demand for using the stuff that all of us are working on. So for the purpose of the reports, we picked L1 fees, L2 fees, and protocol fees. But there is a lot more. So the stuff that's not included in our numbers but could be considered as the measure of the crypto-native economy or the crypto economy would be revenues from centralized exchanges, mining and staking rewards, crypto services, etc., etc. So quick, too long, didn't read. You can find all of the reports under the QR code or under cryptonative.com.xyz. But in 2020, the on-chain revenues were somewhere around 1.4 billion. 2021, the peak of the bull market, 20 billion and going down from there. Now in 2024, we finally started seeing a pickup in the demand and our estimate based on the numbers from the end of October is that it will result in something like $12 to $15 billion. And this is, again, just the on-chain part. So as I said, well, this is going to be imperfect. So there is some napkin math to give you a glimpse into how does the ecosystem actually look like. So how many people do work in crypto? If you take some examples of the roughly known numbers, this is an estimate of figuring out how many people get paid in crypto. This isn't all of the ones that somehow make a living on crypto, but the ones that we could say are employed in a way. So if we take the examples of the biggest companies such as Coinbase. I think they report somewhere around 3.6 thousand people. Binance, roughly 2,500. We take 10 of those companies, 50 companies of the size of roughly EF or Netamind, having 250, 100 small projects, L1s, L2s, you name it, at like 50 people a team, 500 of startups of the size of Pondau, thousands of early stage projects, and tens of thousands of team-ups. That's roughly 100,000 people that we can say are employed in crypto, which isn't a lot, obviously. What's the total market cap? This should be the up-to-date number from this morning. So the tokens and coins only result in 3.2 trillion dollars There is also the market cap which we didn't include in the crypto native economy report, but it's the the crypto economy itself There would be companies like Binance like MicroStrategy. Maybe even Robinhood We would be somewhere below 200 billion dollars. I think coinbase is at like $85 billion of market cap. Plus, there is a ton of companies that are privately owned. They're like Binance, Chain Analysis, OpenSea. All of those would rank in billions. Obviously, Binance is very likely much higher than that. So how does this reflect on the rest of the economy, the so-called real world? To compare these two, we basically picked these three metrics, the market caps, revenues, and the people. And I hope this will give you some perspective about where we stand today. So comparing the market caps, basically to the stock market cap, we take the stock market caps as, again, the imperfect metric. You can take that as demands to somehow participate on those assets that either can act as a store of value or act as a promise of future value in form of revenues. So the entire tech stock market, by the way, there are overlaps between these, would be today valued at $33 trillion, the banking sector, the publicly traded banks, $10 trillion. Energy sector, likewise, pharma, $6 trillion. Gaming, 4.2. And then there's crypto at like 3.8. Then there is automotive. So basically all of the car manufacturers. And this is very real, right? Like we would all agree that that's the real world and crypto is actually already valued more than this part of the real world. Then you have entertainment, a 2 trillion food industry. That's basically the large corporations. We definitely don't go deeper into the entire economy behind the food industry or any of these, just the publicly traded companies. And finally, airlines. There's one thing I want to focus on, which is the gaming and entertainment comparism. Here are the revenue estimates. Let's just do a quick read-through, but let's focus on the entertainment and gaming. So the entertainment, even though it's valued lower than the gaming industry, and there is some partial overlap, is nearing $900 billion, and the gaming is at like $600 billion in revenues. Crypto, including the crypto native part, including the stake and rewards, including the revenues of like Binance and Coinbase and Kraken and so on, I would argue it's like still below like $100 billion. Now, following up on the people metric, this is the rough estimate of how many people are employed by these sectors. And obviously, there's over 3 billion people who are employed somewhere or are making a living. So this is, again, just zoomed in on the stock companies. But there is an interesting and important fact here. Look at entertainment and gaming, where gaming is, like, valued higher than entertainment. Entertainment still makes the bigger revenue, but also employs more than twice as many people as the entertainment as such. I would argue that the gaming industry is essentially a more effective form of entertainment, where the value per an individual in the segment is much higher than the overall entertainment, because they just create something more efficiently. They create content that can scale better, and people can stay with the content for much longer. My argument would be crypto does very similar thing for finance. And we are still in this very early stages of just few hundred or few hundred thousand people working in the ecosystem and we're yet to see basically the full scope of where crypto can actually compete with the rest of the financial ecosystem and economy. So that's a rough comparison in numbers. I think we are still very early. I mean, we're obviously like Bitcoin, it was started in 2009. The World Wide Web was started in 1989. And look where it has led us. Multiple companies from the internet era being in the top 10. This actually isn't the up-to-date slide. I had to update it this morning because Bitcoin, again, popped up into being the ninth most valuable asset in the world. This is from the infinite market cap. Ethereum is quite close it's the it's a number it's actually 32 now and i would say within a year would actually again see ethereum to uh get pass over like the the giants like mastercard or visa um as a contender in this like globalized ecosystem and if you look at all of these companies, I think it's like very hard to argue against crypto being the real thing. Like this, this is very real. This is very tangible. And it already competes with like companies like Home Depot or Costco or like whatever, or ExxonMobil. So it's definitely nowhere, nowhere near kind of just like a gimmick for a few individuals. So a quick summary. You are the crypto-native economy. Since you're here, I guess like you somehow participate in this ecosystem. You all paid like fees on L1s, L2s. I would definitely encourage you to read the reports and give us some feedback. I'm wearing a t-shirt, Banks Hate Us. It's usually my final slide, but I'm not using it today. But banks hate us because we are winning. And I had multiple talks on the crypto-native economy and the crypto-native generation, where I argued that, especially in the big inevitable market, we are at this stage of, like, now they are fighting us. And I think we are now finally in the stage of actually getting the recognition and being considered real from the rest of the world. Before I depart, this is a slide that I used in 2022, exactly like in the bear market, which basically looked at the crypto native economy numbers and just like concluded was actually super small, despite the valuations. And there was peanuts back then, it's still peanuts today. But there is another peanut. It's an inside joke, I'm not a Trump supporter, but I just think a peanut is hilarious. And I would just say, crypto is very real today already. Today, we're past the first day they'll ignore us, then they will ridicule us, and then they will fight us. I think today we're at the stage where crypto started winning, finally. And I can't wait to see what happens in the next few years. Thank you all for coming. Well, I think we have a couple of minutes for questions. That was awesome. Thank you so much, Joseph. You can scan this QR code and write questions. We have a couple minutes to answer your questions. But please, we need to do it through the, through the QR code. You just, you just take the code and then you can place your question and I will help you with that. So I'll give you one minute to do that. Meanwhile, I wanted to say it's fantastic to have you all here. This DEF CON 7 is going to be epic. It's going to be amazing and all of us and all of you being part of this is really fantastic. So I want you to give yourself an applause for being here today, please. No questions yet. I saw someone raising a hand. Should we just do the questions from people that raised a hand? There's a gentleman right here we can try that meanwhile sure we can come on sure we can so so anyone wants to shout a question? Please. Yes, I'll go. So, where you say we are in the first they ignore you, then they laugh at you, then they fight you, then you win, you're assuming that we're right now in the middle of their fighting us or that we've passed that they're fighting us? That seems very naive. Don't you think there's much more, much harder fights? Probably in the near future. I mean, there will be. But I think at this stage, we basically are past their fighting us. There is a lot of embracement in crypto. You see it like... Take Switzerland as an example um even like us first starting company switzerland we got rejected by multiple banks including like the two and like suricantel banks and so on um and last year they started providing the same crypto services to their regular customers and it's just like that's the that's the early birds right and i would say like we are going to see more and more even banks that will start custodial services for crypto users because the economic demand is there and like more and more even traditional fintechs are embracing that and they just see it as a revenue stream. So I say like now we're winning in the sense of getting the recognition and actually like getting them integrated into our own ecosystem. Maybe naive, but I'm like being in the ecosystem for quite a bit. I'm quite optimistic about this being the stage right now. Perfect. So now we have questions on the QR. So Joseph, could you please talk a bit about consumer payments in crypto stables as a real world usage of tech? That I mean, I'm not sure how much time we have, but I think it's actually becoming like real or with the L2s, with the providers that, like, pay your gas fees. Like, three years ago, that would be very hard. I used to collaborate with this, like, group that was running a crypto-only cafe, and it was a burden, like, actually paying for gas fees and, like, teaching people, like, how it works. Many people used it, but definitely wasn't a real world use case. I would say now with like gas being paid for you on L2s, it's like very, very possible. And I mean, I'm sure we are going to see more businesses just like accepting crypto regularly. And it's been happening for a decade now, especially in the past like few years. Fantastic. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you.",
"eventId": "devcon-7",
- "slot_start": 1731582000000,
- "slot_end": 1731582600000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/19vJbc3_xafMXjoRH6SLUAgIZjg0J4oTsoiFzXzdq3Ao"
+ "slot_start": 1731389400000,
+ "slot_end": 1731390600000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1I8L_RL8n3RI4PQDkpmQfboZc2IVdS6GLh-psdPM4k5s",
+ "resources_slides": null,
+ "speakers": [
+ "josef-je"
+ ]
},
"vector": [
- 0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -173463,6 +173106,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -173477,6 +173121,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -173505,6 +173150,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -173539,10 +173185,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -173585,7 +173227,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -173991,8 +173632,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -174000,6 +173639,7 @@
0,
0,
0,
+ 0,
2,
0,
0,
@@ -174008,52 +173648,51 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "crypto-is-the-real-world-understanding-the-cryptonative-economy",
- "sourceId": "UCZ83J",
- "title": "Crypto is the Real World: Understanding the Cryptonative Economy",
- "description": "Ethereum has often been viewed as a separate, speculative space detached from the \"real world.\" However, recent developments and analyses reveal that the cryptonative economy is not only substantial but also comparable to traditional economies in its scope and dynamics. This talk will delve into the findings of the Cryptonative Economy Reports, highlighting the significant economic demand for Ethereum and showcasing where has Ethereum become the real world already.",
- "track": "Real World Ethereum",
+ "id": "crypto-twitter-is-wrong-this-is-how-rollups-really-work",
+ "sourceId": "YNBTQR",
+ "title": "Crypto Twitter is Wrong: This is How Rollups *Really* Work",
+ "description": "It's 2024, L2s are a critical part of the Ethereum scaling roadmap, and everyone *still* gets Rollups completely wrong. If you think that Optimistic Rollups and ZK Rollups are real things, that Rollups need sequencers to create blocks, or that Rollups need proofs to be secure, you've been completely and utterly bamboozled by the Crypto Twitter intelligentsia. It's time we take back the truth - this is How Rollups *Really* Work.",
+ "track": "Layer 2",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Product",
+ "expertise": "Beginner",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"tags": [
- "Digital Sovereignty",
- "Use Cases",
- "Economics",
- "cryptonative",
- "Digital Sovereignty",
- "Economics",
- "Use Cases"
+ "Protocol Design",
+ "Layer 2s",
+ "Rollups",
+ "explainer",
+ "Layer 2s",
+ "Protocol Design",
+ "Rollups"
],
"keywords": [
- "Real world",
- "Ecosystem",
- "Cryptonativism"
+ "Explainer"
],
- "duration": 991,
+ "duration": 1311,
"language": "en",
- "sources_swarmHash": "9a3b05187a79c6bb70f1acb84dcc9c89cdbac55482d6f2a8c022454a40a42a1c",
- "sources_youtubeId": "Y0u6J1OmPXc",
+ "sources_swarmHash": "6ef1847de49946125226649f6d7f43cc8bb2186fc9f0880a95d2fb7cceaf091d",
+ "sources_youtubeId": "c1IbglrscSU",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f3dccacabd9035b773c0.vtt",
- "transcript_text": " Hey everybody. So crypto is the real world. Today I'm going to try to convince you that crypto isn't a niche anymore, but that in fact it's a blueprint to the future of economy. And one thing that triggered me to pick this topic is that, like, increasingly we started using the term RWAs, the real world assets, which kind of implies that, well, all of the other stuff that we've been using so far isn't the real world. And I actually would like to protest today and make a case about this actually not being the reality. So my name is Joseph. I got into crypto in 2011 thanks to Socroat. Then thanks to Ethereum, I started organizing meetups and started getting my hands dirty. I used to work as a Solidity Dev and Auditor. And then since 2018, I helped the Ethereum Foundation with organizing operations around the R&D teams. And finally, since the beginning of 2022, I started Pondow and started hosting conferences on my own. As mentioned, I used to help with DEF CONs before, so I'm thrilled to see how they've grown. And well, thanks to the team organizing this. I know you can't see the talks, but maybe later this will make you happy. I'll take you to several steps first I'll look at into the terminology what is an economy or what is the crypto native economy and how does it compare to the real world and finally I'll finish out with a quick retrospect of the past few years so what is an economy I'll borrow a definition from the Austrian economics of basically two long-distance reads from Mises and Hayek. An economy is the result of individual actions and choices driven by human purpose and subjective preferences. It is a network of voluntary exchanges and cooperative activities where resources are allocated through the spontaneous interactions of individuals in the market. So we could say it's it's a living organism and here during the talk I'll try to try to describe that living organism very imperfectly because it's very hard to give you the up-to-date numbers so what you see here what you what you're going to see are basically best attempts and estimates and therefore would like to ask you to challenge those numbers and later on reach out or publish articles on your own trying to get those numbers right. Because that's the only way we can actually describe the reality in the best way. So what is the crypto-native economy? With Pond, we've been publishing these crypto-native economy reports for the past several years. And what we attempt is to look into the on-chain revenue. So all of the stuff that happens on-chain as a measurement of that economic interaction, of the demand for using the stuff that all of us are working on. So for the purpose of the reports, we picked L1 fees, L2 fees, and protocol fees. But there is a lot more. So the stuff that's not included in our numbers but could be considered as the measure of the crypto-native economy or the crypto economy would be revenues from centralized exchanges, mining and staking rewards, crypto services, etc., etc. So quick, too long, didn't read. You can find all of the reports under the QR code or under cryptonative.com.xyz. But in 2020, the on-chain revenues were somewhere around 1.4 billion. 2021, the peak of the bull market, 20 billion and going down from there. Now in 2024, we finally started seeing a pickup in the demand and our estimate based on the numbers from the end of October is that it will result in something like $12 to $15 billion. And this is, again, just the on-chain part. So as I said, well, this is going to be imperfect. So there is some napkin math to give you a glimpse into how does the ecosystem actually look like. So how many people do work in crypto? If you take some examples of the roughly known numbers, this is an estimate of figuring out how many people get paid in crypto. This isn't all of the ones that somehow make a living on crypto, but the ones that we could say are employed in a way. So if we take the examples of the biggest companies such as Coinbase. I think they report somewhere around 3.6 thousand people. Binance, roughly 2,500. We take 10 of those companies, 50 companies of the size of roughly EF or Netamind, having 250, 100 small projects, L1s, L2s, you name it, at like 50 people a team, 500 of startups of the size of Pondau, thousands of early stage projects, and tens of thousands of team-ups. That's roughly 100,000 people that we can say are employed in crypto, which isn't a lot, obviously. What's the total market cap? This should be the up-to-date number from this morning. So the tokens and coins only result in 3.2 trillion dollars There is also the market cap which we didn't include in the crypto native economy report, but it's the the crypto economy itself There would be companies like Binance like MicroStrategy. Maybe even Robinhood We would be somewhere below 200 billion dollars. I think coinbase is at like $85 billion of market cap. Plus, there is a ton of companies that are privately owned. They're like Binance, Chain Analysis, OpenSea. All of those would rank in billions. Obviously, Binance is very likely much higher than that. So how does this reflect on the rest of the economy, the so-called real world? To compare these two, we basically picked these three metrics, the market caps, revenues, and the people. And I hope this will give you some perspective about where we stand today. So comparing the market caps, basically to the stock market cap, we take the stock market caps as, again, the imperfect metric. You can take that as demands to somehow participate on those assets that either can act as a store of value or act as a promise of future value in form of revenues. So the entire tech stock market, by the way, there are overlaps between these, would be today valued at $33 trillion, the banking sector, the publicly traded banks, $10 trillion. Energy sector, likewise, pharma, $6 trillion. Gaming, 4.2. And then there's crypto at like 3.8. Then there is automotive. So basically all of the car manufacturers. And this is very real, right? Like we would all agree that that's the real world and crypto is actually already valued more than this part of the real world. Then you have entertainment, a 2 trillion food industry. That's basically the large corporations. We definitely don't go deeper into the entire economy behind the food industry or any of these, just the publicly traded companies. And finally, airlines. There's one thing I want to focus on, which is the gaming and entertainment comparism. Here are the revenue estimates. Let's just do a quick read-through, but let's focus on the entertainment and gaming. So the entertainment, even though it's valued lower than the gaming industry, and there is some partial overlap, is nearing $900 billion, and the gaming is at like $600 billion in revenues. Crypto, including the crypto native part, including the stake and rewards, including the revenues of like Binance and Coinbase and Kraken and so on, I would argue it's like still below like $100 billion. Now, following up on the people metric, this is the rough estimate of how many people are employed by these sectors. And obviously, there's over 3 billion people who are employed somewhere or are making a living. So this is, again, just zoomed in on the stock companies. But there is an interesting and important fact here. Look at entertainment and gaming, where gaming is, like, valued higher than entertainment. Entertainment still makes the bigger revenue, but also employs more than twice as many people as the entertainment as such. I would argue that the gaming industry is essentially a more effective form of entertainment, where the value per an individual in the segment is much higher than the overall entertainment, because they just create something more efficiently. They create content that can scale better, and people can stay with the content for much longer. My argument would be crypto does very similar thing for finance. And we are still in this very early stages of just few hundred or few hundred thousand people working in the ecosystem and we're yet to see basically the full scope of where crypto can actually compete with the rest of the financial ecosystem and economy. So that's a rough comparison in numbers. I think we are still very early. I mean, we're obviously like Bitcoin, it was started in 2009. The World Wide Web was started in 1989. And look where it has led us. Multiple companies from the internet era being in the top 10. This actually isn't the up-to-date slide. I had to update it this morning because Bitcoin, again, popped up into being the ninth most valuable asset in the world. This is from the infinite market cap. Ethereum is quite close it's the it's a number it's actually 32 now and i would say within a year would actually again see ethereum to uh get pass over like the the giants like mastercard or visa um as a contender in this like globalized ecosystem and if you look at all of these companies, I think it's like very hard to argue against crypto being the real thing. Like this, this is very real. This is very tangible. And it already competes with like companies like Home Depot or Costco or like whatever, or ExxonMobil. So it's definitely nowhere, nowhere near kind of just like a gimmick for a few individuals. So a quick summary. You are the crypto-native economy. Since you're here, I guess like you somehow participate in this ecosystem. You all paid like fees on L1s, L2s. I would definitely encourage you to read the reports and give us some feedback. I'm wearing a t-shirt, Banks Hate Us. It's usually my final slide, but I'm not using it today. But banks hate us because we are winning. And I had multiple talks on the crypto-native economy and the crypto-native generation, where I argued that, especially in the big inevitable market, we are at this stage of, like, now they are fighting us. And I think we are now finally in the stage of actually getting the recognition and being considered real from the rest of the world. Before I depart, this is a slide that I used in 2022, exactly like in the bear market, which basically looked at the crypto native economy numbers and just like concluded was actually super small, despite the valuations. And there was peanuts back then, it's still peanuts today. But there is another peanut. It's an inside joke, I'm not a Trump supporter, but I just think a peanut is hilarious. And I would just say, crypto is very real today already. Today, we're past the first day they'll ignore us, then they will ridicule us, and then they will fight us. I think today we're at the stage where crypto started winning, finally. And I can't wait to see what happens in the next few years. Thank you all for coming. Well, I think we have a couple of minutes for questions. That was awesome. Thank you so much, Joseph. You can scan this QR code and write questions. We have a couple minutes to answer your questions. But please, we need to do it through the, through the QR code. You just, you just take the code and then you can place your question and I will help you with that. So I'll give you one minute to do that. Meanwhile, I wanted to say it's fantastic to have you all here. This DEF CON 7 is going to be epic. It's going to be amazing and all of us and all of you being part of this is really fantastic. So I want you to give yourself an applause for being here today, please. No questions yet. I saw someone raising a hand. Should we just do the questions from people that raised a hand? There's a gentleman right here we can try that meanwhile sure we can come on sure we can so so anyone wants to shout a question? Please. Yes, I'll go. So, where you say we are in the first they ignore you, then they laugh at you, then they fight you, then you win, you're assuming that we're right now in the middle of their fighting us or that we've passed that they're fighting us? That seems very naive. Don't you think there's much more, much harder fights? Probably in the near future. I mean, there will be. But I think at this stage, we basically are past their fighting us. There is a lot of embracement in crypto. You see it like... Take Switzerland as an example um even like us first starting company switzerland we got rejected by multiple banks including like the two and like suricantel banks and so on um and last year they started providing the same crypto services to their regular customers and it's just like that's the that's the early birds right and i would say like we are going to see more and more even banks that will start custodial services for crypto users because the economic demand is there and like more and more even traditional fintechs are embracing that and they just see it as a revenue stream. So I say like now we're winning in the sense of getting the recognition and actually like getting them integrated into our own ecosystem. Maybe naive, but I'm like being in the ecosystem for quite a bit. I'm quite optimistic about this being the stage right now. Perfect. So now we have questions on the QR. So Joseph, could you please talk a bit about consumer payments in crypto stables as a real world usage of tech? That I mean, I'm not sure how much time we have, but I think it's actually becoming like real or with the L2s, with the providers that, like, pay your gas fees. Like, three years ago, that would be very hard. I used to collaborate with this, like, group that was running a crypto-only cafe, and it was a burden, like, actually paying for gas fees and, like, teaching people, like, how it works. Many people used it, but definitely wasn't a real world use case. I would say now with like gas being paid for you on L2s, it's like very, very possible. And I mean, I'm sure we are going to see more businesses just like accepting crypto regularly. And it's been happening for a decade now, especially in the past like few years. Fantastic. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you so much, Joseph. Please give a big applause for Joseph and this great talk. Appreciate it. Thank you.",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673311fc3a168eb535f73a32.vtt",
+ "transcript_text": " Tanya Cushman Reviewer:\"Petey Desai\", Where are we? There we go. Oh, wait, that's it. Alright, so I've been kind of ill the last couple of days, sitting on the toilet, so if I seem defeated and disheveled, that's why. But this isn't the first time I was getting ill on this trip. I've been in Bangkok for about a month, or in Thailand. And the last time I was doing this, I started tweeting and getting really mad at people on the internet. And I realized that I'm not the only one that needs to get their shit together. We better start agreeing on stuff where Ethereum is cooked. So, that's the new talk. together, we better start agreeing on stuff where Ethereum is cooked. So that's the new talk. I'm going to start this talk by telling you a little story. It's December 11, 1998. It's a mild day, Cape Canaveral, Florida. And some NASA, smart cookies at NASA are going to send an orbiter over to Mars, right? So they throw that thing on the rocket and send it off. Wow, yeah, neat, right? Great. They throw that thing on the rocket and send it off. Wow, yeah, neat. Great. It's a long, tense journey to Mars. This whole thing takes nine months, $500 million, a bunch of people's entire lives built into this thing. It goes all the way to Mars and it's finally time for orbital insertion. This is what's supposed to happen. Rocket goes like this. Oh, look, it orbits Mars. That's what we expect. Yeah, that's what we want. But what actually happens is this. Oh, oh, oh, no, it's way too low. And then bam, you know, the whole thing falls apart. The whole thing slams into Mars' atmosphere, falls to pieces. So why? What happened? What happened to this thing? Well, the smart cookies at NASA went over to Lockheed and said, hey, Lockheed, you know what? Can you pass me that meter stick? And Lockheed is like, yeah. And Lockheed gives the meter stick to NASA. And NASA is like, hey, Lockheed, what? This is a bleeping yardstick. It turns out that Lockheed the whole time was building instruments that were returning data in US customary units. Why? Everyone uses metric. But the moral of this story, right, oopsies, sorry, the moral of this story is that shared definitions make or break projects. If you don't agree on the words that we're saying, you're never going to get anywhere. And today, while Ethereum is facing more competition than ever, we're wasting so much time talking past each other. We're all saying the same things with different words, and everyone hates each other. So I asked the internet on Twitter what they think an L2 is, and here are some of the responses I got. An L2 is a chain that settles to an L1. An L2 is a cultural extension of Ethereum. Like cutlery, a layer 2 is a function description, not a specific design or form. And I give up on the other definition. Let's just stop saying L2. It's a nightmare. The reality is that we can't build the future of Ethereum if we keep using these differing definitions. We can't do it unless we have shared clear definitions. Shared clear definitions allow us to see the whole picture, right? And you can fill in the gaps. If you're building a puzzle, what do you do? You build the frame first, and then you fill in the gaps. Right now, we're building Ethereum by just putting puzzles in random pieces. And so we better start writing a dictionary, or we're going to end up like the Mars orbiter. So call it whatever you want, but I think we need to build this. I think we need to build the encyclopedia of theory and I think we need to get on it now. Like any good dictionary, the first word in any encyclopedia is aardvark. That's right. And Arthur is an aardvark. I don't know why. It doesn't look like an aardvark. It looks like a bear. I don't think they should have called them an aardvark. The next word is rollup. Why rollup? When I asked people on Twitter what an L2 is, nobody could agree. When I asked people what a rollup was, I got surprisingly coherent answers. The average that I got was this. A rollup is just a normal blockchain that uses another blockchain for ordering and data availability. All right. That's that. So let's kind of walk through it. Let's explain this, right? Blockchain 101. What even is a blockchain, right? Let's crack open Ethereum. What is a blockchain? Well, it's composed of three main parts. We have state. That's what the world of the blockchain looks like. We have state. That's what the world of the blockchain looks like. We have transactions. That's how people change the blockchain. And we have the state transition function, which is the rules by which a transaction actually modifies the state. We have two properties that are really important for any blockchain. We have ordering, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat Person, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat person, right? That's fine. We know that. That works. But if we swap the ordering, and we say that the first transaction happened second and vice versa, and Timmy tries to send one ETH to Pretty Hat person, well, if we look at the initial state, we know that Timmy didn't have any ETH, and so this doesn't work, right? So ordering is really important. No ordering, no blockchain. Data availability is critical, right? What is that? Well, it's really just a fancy way to say that you can actually download the transactions. If you can't download the transactions and they fade away, then the whole blockchain fades away, right? If you can't execute the transactions because you don't have them in the first place, you can't compute the state. No transactions, no blockchain. All right. So blockchains use consensus mechanisms to establish ordering and data availability, and there's an asterisk there, but don't worry about it. But it basically works. So, you know, we know what a consensus mechanism is. We have Bitcoin, right? So whoever has the most money and lights it on fire wins. That's proof of work. We have Ethereum. Whoever has the most money wins. That's great. Very human. Love that. It's not plutocratic at all. So these futuristic systems are complicated and costly. And the reality is that they're very difficult and expensive to build in the first place. I mean, you try to build Ethereum's proof of stake from scratch, good luck. Then they're also challenging to maintain. So even if you didn't build them in the first place, just to run them is really hard. And I think this is underappreciated, but usually you need a token to reward participants, right? Bitcoin has Bitcoin. ETH has ETH. And the reality is that a lot of people for a lot of reasons don't want to make tokens. Cool. So rollups solve this problem by outsourcing consensus to another blockchain, right? This is all that a rollup really does. Let's explain how a rollup works by just giving an example. So Timmy wants to send a transaction. What does Timmy do? He sticks the transaction into the mempool on the rollup, just like you would in Ethereum. And then the validator or sometimes the block producer, we call it the sequencer sometimes, takes that transaction and shoves it into a block with lots of other transactions. And then it puts on its little Timmy hat and it grabs that block. And it goes over to the Ethereum mempool where it tosses the block into an Ethereum transaction. Puts the block into the Ethereum mempool. Gets picked up by an Ethereum block producer. Puts it into a block. This is a bridge, but it gives you the basic idea. Validators come in. They say, okay, sign off, looks good. Take the block, shove it into the Ethereum blockchain. Now if you open that transaction, back up, there you go, there's your rollup block. And now there might be older transactions that have older rollup blocks and older transactions that have older rollup blocks. And because all of these blocks and the block data is just being shoved into Ethereum transactions, you get all of the guarantees from Ethereum about ordering and data availability about Ethereum transactions, right? If you know that Ethereum transactions are going to be ordered, then you know that if you put a rollup block into an Ethereum transaction, it will be ordered too. So to kind of recap that, a rollup is just a normal blockchain that uses another blockchain for ordering and data availability. Right? Okay. So if you've watched this talk and you kind of have some idea of what a rollup is, then you might be asking where does the ZK or optimistic bit come in? Because we always talk about ZK rollups and optimistic rollups. I never mention ZK or optimistic stuff at all in that description. In order to understand this, we first have to talk about bridges. What are bridges? Well, you've probably used one before. We kind of know what they do. They're applications. They let you send tokens and data and stuff between different blockchains. How do they actually work? All bridges basically work the same way. You have two chains and you stick two smart contracts, one on each chain. These are two independent chains. And someone comes by, Timmy comes by and puts an ETH or whatever into the smart contract on the first chain. And then Timmy goes to the smart contract on the other chain and says, money, please. And now the smart contract on the first chain needs to think, well, how am I actually going to verify what happened on OP main net? The problem is that this is a smart contract. I mean, if you were going to do this, you would probably just run an OP mainnet node. And it would love to do this as well. You could just run a full OP mainnet node inside of the smart contract. But it's a smart contract. It can't do that. It's a resource constrained environment and we're not able to actually verify the full chain explicitly like this. So instead, the smart contract asks for a proof. It asks for a succinct way to verify the state on the other chain. And then Timmy comes up with a proof, gives it to the bridge smart contract. And the bridge smart contract takes a look at that proof, verifies it according to some rules, and then poops out some ETH on the other side. So Timmy walks off and now you've completed your bridge transaction. This is generally the way that all bridges work. Whether it's a multisig proof or an optimistic proof or a ZK proof, each time what's happening is the smart contract is using some abridged metric to decide what's going on on the foreign chain. So what I want you to get out of this is that proofs are things that bridges use. Roll-ups don't use proofs. Bridges use proofs, right? And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, ZK rollup or optimistic rollup, doesn't make a lot of sense. Because rollups use proofs. Or rollups, sorry, rollups don't use proofs. Bridges use proofs, right? So if it's the bridge, if ZK or optimistic is a descriptor of the bridge, then why are we applying that descriptor to the rollup? Where does this come from? I think there's a lot of historical context. The answer is basically rollups think that bridges are useful. This is because it's useful to be able to pull economic activity from one chain to another. And so rollup teams build these official bridges. And these bridges, because of the special relationship between a rollup and its parent chain, can be these kind of special bridges that are more secure than bridges between two arbitrary chains. The fact that it's the rollup teams that build these bridges is just a coincidence of the fact that the rollup teams know the most about the thing. There's nothing really stopping any arbitrary person from building that bridge. Because it's official and because it is the branding of the chain, it becomes naturally popular. And when people put more and more assets into that bridge, it gets more and more influence over the social consensus of the L2. If the L2 wants to fork, the bridge has to agree, right? Or all of those assets on the bridge are not going to be worth anything on the forked chain. And then, of course, at the end of the day, the official bridge has some sort of proof system, and the result is that the rollup gets its name from that official bridge. All right. So really to hammer it home one last time, proofs are things that bridges use. Rollups don't use proofs. Bridges do. So what? What's the point of all this? Well, I'm glad I'm disheveled because I can look really crazy when I'm saying this. But essentially, all this stuff about ZK rollups and optimistic rollups and there being a war and fighting between all these teams is kind of fake news and we're just creating this tension between teams for no good reason. Right? And the other thing is that ZK and optimistic rollup is just really terribly limiting. If you think this way, you can't imagine new things. Like what if there's a chain with two massive bridges at the same time and one is a ZK and one is an optimistic bridge. What is it, a ZK rollup or an optimistic rollup? Who knows? What if it's a chain with no bridge at all and someone puts a bridge on that chain but the person who does that is just a random person? What if there's a chain that posts blocks to two other blockchains? Or if there's a bridge with more than one proof system? All of these things are things that you can imagine if you're not constrained in this way. Again, at the end of the day, Wittgenstein, good quote, limits of my language are the limits of my world. The reality is that our language just doesn't leave any room for novel constructions. When people want to build something new, they can't. Because they don't have the language to do it. So you're stuck with two really bad options. You can see this. Option number one is you make up a completely new term. You get L1, L2, L3, optimistic rollup, plasma, valletium, sovereign rollup. No one knows what any of this stuff is. If I quizzed half of you, you would all be wrong. No one knows what this stuff is. How am I supposed to convince a user to use my product if nobody knows what it is? And the other option, which if you have less scruples, you just do this. You just co-opt an existing term. You take a term that other people like, like EVM equivalence or roll-up or L2 or whatever, and you just decide that your chain is going to have that too. And because we don't have good definitions, everyone loses, right? Every single person loses. Teams lose. users lose. The reality is that everyone's confused. And so our language just isn't flexible enough for people to be able to build these things. The end result of all this is that no one's working together. You know how many times I've heard that quote? The fact that there's an I think in front of that is insane. What do you mean I think we're all building the same thing? We should know if we're all building the same thing. It doesn't make any sense. Why are we doing this to ourselves? And we're doing it because we don't have good shared definitions. So I was trying to figure out a couple of weeks ago, I'm scaffolding these slides, I'm trying to figure out how to end this talk. And then this thing happens and it kind of fits perfectly with the rest of the talk. . Booster coming in hot for booster touch. Booster FTS is saved. . And I have 13 of those Raptor engines and this view is incredible right now. I can't wait for us to hear the sonic boom. We can see those chopsticks now. This is absolutely insane! It's the first ever attempt we have successfully caught a super heavy booster. The villa has caught the booster. Ship avionics power plant phenomenal. Starship has entered the atmosphere. Those people share definitions. All of them. They all agree on the same thing. And if you're Ethereum today, you can't do that. Ethereum can't land that. And I know every single person wants to experience what those people experience, but the reality is Ethereum today can't do it. But we could, right? We could catch boosters. We could do it. Whatever. But we have to start working together to create shared definitions. If we don't do this, it's never going to happen. So please join me. Try to help write the encyclopedia theory. We've got two definitions. We've got rollup and aardvark. That's a really good start. And thank you. Please help formalize stuff. Scan the QR code. There's an empty GitHub repo. I'll add aardvark to this later on. And I'll take any and all questions. Thank you very much. Much appreciated. . . . That was a great talk, Calvin. Thanks. All right. So we have some great questions over here. Let's go through the first one. Wow, very interesting. Is lasagna a layer, too? I mean, if your lasagna a layer, too? I mean, if your lasagna has two layers, I don't think it's very good lasagna. Let's put it that way. Is a croissant a roll-up? Yeah, why not? I mean, might as well be. You could ask someone on Twitter. They'd say, yeah. Can we see the rocket launch again? I feel like it might take up too much time, but I'll send you the video afterwards if you come to me. All right. So I'm going to mark this as answered. What about croissant? Is that a rollup? Because we do have one vote over here. Which one? Is a croissant a rollup? Yes. A croissant is a rollup. Yeah. What are some other terms and concepts that need defining? That's a really good question. I think L2 is a hopeless term. So let's not bother with that one at first. But things like bridge is a really easy thing to define. The stages for rollups, right? Stage 0, stage 1, stage 2. I think those things can be defined very, very well, and that would help a lot of people. And kind of just, I mean, honestly, at the end of the day, more than defining new terms, I'd like for the ecosystem to start throwing away terms and redefining things like sovereign roll-up or validium or whatever in terms of these simpler things that we can all agree on. Cool. And these questions, guys. When will I be bleaching my hair again? I don't know. I mean, today, I guess. Why not? Great. I'll bleach my hair today and I'll whatever. Why not? What are some other terms and concepts? We talked about that. Rollups don't use proofs. Bridges use proofs. But rollups use bridges, right? Without a bridge, what distinguishes a rollup from a foreign chain? Well, all chains use bridges, right? The fact that we have bridges is not unique to rollups. The unique thing about rollups is that it allows you to build a special type of bridge that has better security properties than if you just had two completely unrelated chains. But the fact that that's true doesn't mean that that bridge has to be built by the same people that built the rollup and it doesn't mean that you can only have one of these. You don't even have to have any of them if you don't want. Since rollups outsource consensus, does it mean that decentralizing the rollup doesn't make sense? This is kind of a contentious topic. I would say that the correct answer here is that decentralizing the rollup means a different thing than it would on the layer one, because you have most of your security properties, even if you have a centralized block producer or a centralized sequencer, you don't lose liveness, right? Because you can do this special thing between the rollup and the parent chain, and you don't lose safety. And so this is generally why doing stuff like decentralizing the sequencer has been relatively low on the priority list of a lot of rollup teams, because you have very good security properties and you don't really lose much, except for this kind of short-term liveness. Now eventually short-term liveness will become the most critical part. But usually focusing time and effort on the bridges and making those bridges robust takes up more time for people. All right. I guess we have a few more minutes for one more question. How does sharding fit into this? It's what I do on the toilet all day. How does sharding fit into this? I don't know. This is such a confusing question. I could spend a whole minute working on it. I'm going to skip that one. Perfect. All right, we can leave it there. Yeah, great. All right. Great. Thank you, Kevin. Thank you, Kevin. Thank you.",
"eventId": "devcon-7",
- "slot_start": 1731389400000,
- "slot_end": 1731390600000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1I8L_RL8n3RI4PQDkpmQfboZc2IVdS6GLh-psdPM4k5s",
+ "slot_start": 1731398400000,
+ "slot_end": 1731400200000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Zq5DAdb9ha3cFF-gOzk6L82ORlY9uvzFl7T5sV1W2mg",
"resources_slides": null,
"speakers": [
- "josef-je"
+ "kelvin-fichter"
]
},
"vector": [
@@ -174063,6 +173702,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -174258,9 +173898,12 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
0,
0,
- 6,
0,
0,
0,
@@ -174848,6 +174491,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -174859,14 +174503,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -174875,6 +174511,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -174888,7 +174525,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -175370,15 +175006,15 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -175392,48 +175028,42 @@
},
{
"session": {
- "id": "crypto-twitter-is-wrong-this-is-how-rollups-really-work",
- "sourceId": "YNBTQR",
- "title": "Crypto Twitter is Wrong: This is How Rollups *Really* Work",
- "description": "It's 2024, L2s are a critical part of the Ethereum scaling roadmap, and everyone *still* gets Rollups completely wrong. If you think that Optimistic Rollups and ZK Rollups are real things, that Rollups need sequencers to create blocks, or that Rollups need proofs to be secure, you've been completely and utterly bamboozled by the Crypto Twitter intelligentsia. It's time we take back the truth - this is How Rollups *Really* Work.",
- "track": "Layer 2",
+ "id": "cuevm-gpu-accelerated-evm-for-security-and-beyond",
+ "sourceId": "PQBKHF",
+ "title": "CuEVM: GPU-Accelerated EVM for Security and Beyond",
+ "description": "In this talk, we present CuEVM, an EVM executor implemented in CUDA for running a massive number of transactions in parallel. Its primary application is to accelerate fuzzing by testing transactions in multiple sandbox EVMs on GPUs. Additionally, we have integrated it into Goevmlab to support a broader range of use cases. We will discuss the design choices, challenges, results, and future plans to leverage CuEVM beyond fuzzing.",
+ "track": "Security",
"type": "Talk",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Protocol Design",
- "Layer 2s",
- "Rollups",
- "explainer",
- "Layer 2s",
- "Protocol Design",
- "Rollups"
- ],
"keywords": [
- "Explainer"
+ "Parallel",
+ "EVM"
+ ],
+ "tags": [
+ "Scalability",
+ "Security",
+ "Fuzzing",
+ "EVM",
+ "parallel",
+ "Fuzzing",
+ "Scalability",
+ "Security"
],
- "duration": 1311,
"language": "en",
- "sources_swarmHash": "6ef1847de49946125226649f6d7f43cc8bb2186fc9f0880a95d2fb7cceaf091d",
- "sources_youtubeId": "c1IbglrscSU",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673311fc3a168eb535f73a32.vtt",
- "transcript_text": " Tanya Cushman Reviewer:\"Petey Desai\", Where are we? There we go. Oh, wait, that's it. Alright, so I've been kind of ill the last couple of days, sitting on the toilet, so if I seem defeated and disheveled, that's why. But this isn't the first time I was getting ill on this trip. I've been in Bangkok for about a month, or in Thailand. And the last time I was doing this, I started tweeting and getting really mad at people on the internet. And I realized that I'm not the only one that needs to get their shit together. We better start agreeing on stuff where Ethereum is cooked. So, that's the new talk. together, we better start agreeing on stuff where Ethereum is cooked. So that's the new talk. I'm going to start this talk by telling you a little story. It's December 11, 1998. It's a mild day, Cape Canaveral, Florida. And some NASA, smart cookies at NASA are going to send an orbiter over to Mars, right? So they throw that thing on the rocket and send it off. Wow, yeah, neat, right? Great. They throw that thing on the rocket and send it off. Wow, yeah, neat. Great. It's a long, tense journey to Mars. This whole thing takes nine months, $500 million, a bunch of people's entire lives built into this thing. It goes all the way to Mars and it's finally time for orbital insertion. This is what's supposed to happen. Rocket goes like this. Oh, look, it orbits Mars. That's what we expect. Yeah, that's what we want. But what actually happens is this. Oh, oh, oh, no, it's way too low. And then bam, you know, the whole thing falls apart. The whole thing slams into Mars' atmosphere, falls to pieces. So why? What happened? What happened to this thing? Well, the smart cookies at NASA went over to Lockheed and said, hey, Lockheed, you know what? Can you pass me that meter stick? And Lockheed is like, yeah. And Lockheed gives the meter stick to NASA. And NASA is like, hey, Lockheed, what? This is a bleeping yardstick. It turns out that Lockheed the whole time was building instruments that were returning data in US customary units. Why? Everyone uses metric. But the moral of this story, right, oopsies, sorry, the moral of this story is that shared definitions make or break projects. If you don't agree on the words that we're saying, you're never going to get anywhere. And today, while Ethereum is facing more competition than ever, we're wasting so much time talking past each other. We're all saying the same things with different words, and everyone hates each other. So I asked the internet on Twitter what they think an L2 is, and here are some of the responses I got. An L2 is a chain that settles to an L1. An L2 is a cultural extension of Ethereum. Like cutlery, a layer 2 is a function description, not a specific design or form. And I give up on the other definition. Let's just stop saying L2. It's a nightmare. The reality is that we can't build the future of Ethereum if we keep using these differing definitions. We can't do it unless we have shared clear definitions. Shared clear definitions allow us to see the whole picture, right? And you can fill in the gaps. If you're building a puzzle, what do you do? You build the frame first, and then you fill in the gaps. Right now, we're building Ethereum by just putting puzzles in random pieces. And so we better start writing a dictionary, or we're going to end up like the Mars orbiter. So call it whatever you want, but I think we need to build this. I think we need to build the encyclopedia of theory and I think we need to get on it now. Like any good dictionary, the first word in any encyclopedia is aardvark. That's right. And Arthur is an aardvark. I don't know why. It doesn't look like an aardvark. It looks like a bear. I don't think they should have called them an aardvark. The next word is rollup. Why rollup? When I asked people on Twitter what an L2 is, nobody could agree. When I asked people what a rollup was, I got surprisingly coherent answers. The average that I got was this. A rollup is just a normal blockchain that uses another blockchain for ordering and data availability. All right. That's that. So let's kind of walk through it. Let's explain this, right? Blockchain 101. What even is a blockchain, right? Let's crack open Ethereum. What is a blockchain? Well, it's composed of three main parts. We have state. That's what the world of the blockchain looks like. We have state. That's what the world of the blockchain looks like. We have transactions. That's how people change the blockchain. And we have the state transition function, which is the rules by which a transaction actually modifies the state. We have two properties that are really important for any blockchain. We have ordering, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat Person, right? Now, let's say that Wizard Hat sends one ETH to Timmy, and Timmy sends one ETH to Pretty Hat person, right? That's fine. We know that. That works. But if we swap the ordering, and we say that the first transaction happened second and vice versa, and Timmy tries to send one ETH to Pretty Hat person, well, if we look at the initial state, we know that Timmy didn't have any ETH, and so this doesn't work, right? So ordering is really important. No ordering, no blockchain. Data availability is critical, right? What is that? Well, it's really just a fancy way to say that you can actually download the transactions. If you can't download the transactions and they fade away, then the whole blockchain fades away, right? If you can't execute the transactions because you don't have them in the first place, you can't compute the state. No transactions, no blockchain. All right. So blockchains use consensus mechanisms to establish ordering and data availability, and there's an asterisk there, but don't worry about it. But it basically works. So, you know, we know what a consensus mechanism is. We have Bitcoin, right? So whoever has the most money and lights it on fire wins. That's proof of work. We have Ethereum. Whoever has the most money wins. That's great. Very human. Love that. It's not plutocratic at all. So these futuristic systems are complicated and costly. And the reality is that they're very difficult and expensive to build in the first place. I mean, you try to build Ethereum's proof of stake from scratch, good luck. Then they're also challenging to maintain. So even if you didn't build them in the first place, just to run them is really hard. And I think this is underappreciated, but usually you need a token to reward participants, right? Bitcoin has Bitcoin. ETH has ETH. And the reality is that a lot of people for a lot of reasons don't want to make tokens. Cool. So rollups solve this problem by outsourcing consensus to another blockchain, right? This is all that a rollup really does. Let's explain how a rollup works by just giving an example. So Timmy wants to send a transaction. What does Timmy do? He sticks the transaction into the mempool on the rollup, just like you would in Ethereum. And then the validator or sometimes the block producer, we call it the sequencer sometimes, takes that transaction and shoves it into a block with lots of other transactions. And then it puts on its little Timmy hat and it grabs that block. And it goes over to the Ethereum mempool where it tosses the block into an Ethereum transaction. Puts the block into the Ethereum mempool. Gets picked up by an Ethereum block producer. Puts it into a block. This is a bridge, but it gives you the basic idea. Validators come in. They say, okay, sign off, looks good. Take the block, shove it into the Ethereum blockchain. Now if you open that transaction, back up, there you go, there's your rollup block. And now there might be older transactions that have older rollup blocks and older transactions that have older rollup blocks. And because all of these blocks and the block data is just being shoved into Ethereum transactions, you get all of the guarantees from Ethereum about ordering and data availability about Ethereum transactions, right? If you know that Ethereum transactions are going to be ordered, then you know that if you put a rollup block into an Ethereum transaction, it will be ordered too. So to kind of recap that, a rollup is just a normal blockchain that uses another blockchain for ordering and data availability. Right? Okay. So if you've watched this talk and you kind of have some idea of what a rollup is, then you might be asking where does the ZK or optimistic bit come in? Because we always talk about ZK rollups and optimistic rollups. I never mention ZK or optimistic stuff at all in that description. In order to understand this, we first have to talk about bridges. What are bridges? Well, you've probably used one before. We kind of know what they do. They're applications. They let you send tokens and data and stuff between different blockchains. How do they actually work? All bridges basically work the same way. You have two chains and you stick two smart contracts, one on each chain. These are two independent chains. And someone comes by, Timmy comes by and puts an ETH or whatever into the smart contract on the first chain. And then Timmy goes to the smart contract on the other chain and says, money, please. And now the smart contract on the first chain needs to think, well, how am I actually going to verify what happened on OP main net? The problem is that this is a smart contract. I mean, if you were going to do this, you would probably just run an OP mainnet node. And it would love to do this as well. You could just run a full OP mainnet node inside of the smart contract. But it's a smart contract. It can't do that. It's a resource constrained environment and we're not able to actually verify the full chain explicitly like this. So instead, the smart contract asks for a proof. It asks for a succinct way to verify the state on the other chain. And then Timmy comes up with a proof, gives it to the bridge smart contract. And the bridge smart contract takes a look at that proof, verifies it according to some rules, and then poops out some ETH on the other side. So Timmy walks off and now you've completed your bridge transaction. This is generally the way that all bridges work. Whether it's a multisig proof or an optimistic proof or a ZK proof, each time what's happening is the smart contract is using some abridged metric to decide what's going on on the foreign chain. So what I want you to get out of this is that proofs are things that bridges use. Roll-ups don't use proofs. Bridges use proofs, right? And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, And this has some really weird implications. I really want to have you internalize this. Because it sort of means that this word that we've been throwing around, ZK rollup or optimistic rollup, doesn't make a lot of sense. Because rollups use proofs. Or rollups, sorry, rollups don't use proofs. Bridges use proofs, right? So if it's the bridge, if ZK or optimistic is a descriptor of the bridge, then why are we applying that descriptor to the rollup? Where does this come from? I think there's a lot of historical context. The answer is basically rollups think that bridges are useful. This is because it's useful to be able to pull economic activity from one chain to another. And so rollup teams build these official bridges. And these bridges, because of the special relationship between a rollup and its parent chain, can be these kind of special bridges that are more secure than bridges between two arbitrary chains. The fact that it's the rollup teams that build these bridges is just a coincidence of the fact that the rollup teams know the most about the thing. There's nothing really stopping any arbitrary person from building that bridge. Because it's official and because it is the branding of the chain, it becomes naturally popular. And when people put more and more assets into that bridge, it gets more and more influence over the social consensus of the L2. If the L2 wants to fork, the bridge has to agree, right? Or all of those assets on the bridge are not going to be worth anything on the forked chain. And then, of course, at the end of the day, the official bridge has some sort of proof system, and the result is that the rollup gets its name from that official bridge. All right. So really to hammer it home one last time, proofs are things that bridges use. Rollups don't use proofs. Bridges do. So what? What's the point of all this? Well, I'm glad I'm disheveled because I can look really crazy when I'm saying this. But essentially, all this stuff about ZK rollups and optimistic rollups and there being a war and fighting between all these teams is kind of fake news and we're just creating this tension between teams for no good reason. Right? And the other thing is that ZK and optimistic rollup is just really terribly limiting. If you think this way, you can't imagine new things. Like what if there's a chain with two massive bridges at the same time and one is a ZK and one is an optimistic bridge. What is it, a ZK rollup or an optimistic rollup? Who knows? What if it's a chain with no bridge at all and someone puts a bridge on that chain but the person who does that is just a random person? What if there's a chain that posts blocks to two other blockchains? Or if there's a bridge with more than one proof system? All of these things are things that you can imagine if you're not constrained in this way. Again, at the end of the day, Wittgenstein, good quote, limits of my language are the limits of my world. The reality is that our language just doesn't leave any room for novel constructions. When people want to build something new, they can't. Because they don't have the language to do it. So you're stuck with two really bad options. You can see this. Option number one is you make up a completely new term. You get L1, L2, L3, optimistic rollup, plasma, valletium, sovereign rollup. No one knows what any of this stuff is. If I quizzed half of you, you would all be wrong. No one knows what this stuff is. How am I supposed to convince a user to use my product if nobody knows what it is? And the other option, which if you have less scruples, you just do this. You just co-opt an existing term. You take a term that other people like, like EVM equivalence or roll-up or L2 or whatever, and you just decide that your chain is going to have that too. And because we don't have good definitions, everyone loses, right? Every single person loses. Teams lose. users lose. The reality is that everyone's confused. And so our language just isn't flexible enough for people to be able to build these things. The end result of all this is that no one's working together. You know how many times I've heard that quote? The fact that there's an I think in front of that is insane. What do you mean I think we're all building the same thing? We should know if we're all building the same thing. It doesn't make any sense. Why are we doing this to ourselves? And we're doing it because we don't have good shared definitions. So I was trying to figure out a couple of weeks ago, I'm scaffolding these slides, I'm trying to figure out how to end this talk. And then this thing happens and it kind of fits perfectly with the rest of the talk. . Booster coming in hot for booster touch. Booster FTS is saved. . And I have 13 of those Raptor engines and this view is incredible right now. I can't wait for us to hear the sonic boom. We can see those chopsticks now. This is absolutely insane! It's the first ever attempt we have successfully caught a super heavy booster. The villa has caught the booster. Ship avionics power plant phenomenal. Starship has entered the atmosphere. Those people share definitions. All of them. They all agree on the same thing. And if you're Ethereum today, you can't do that. Ethereum can't land that. And I know every single person wants to experience what those people experience, but the reality is Ethereum today can't do it. But we could, right? We could catch boosters. We could do it. Whatever. But we have to start working together to create shared definitions. If we don't do this, it's never going to happen. So please join me. Try to help write the encyclopedia theory. We've got two definitions. We've got rollup and aardvark. That's a really good start. And thank you. Please help formalize stuff. Scan the QR code. There's an empty GitHub repo. I'll add aardvark to this later on. And I'll take any and all questions. Thank you very much. Much appreciated. . . . That was a great talk, Calvin. Thanks. All right. So we have some great questions over here. Let's go through the first one. Wow, very interesting. Is lasagna a layer, too? I mean, if your lasagna a layer, too? I mean, if your lasagna has two layers, I don't think it's very good lasagna. Let's put it that way. Is a croissant a roll-up? Yeah, why not? I mean, might as well be. You could ask someone on Twitter. They'd say, yeah. Can we see the rocket launch again? I feel like it might take up too much time, but I'll send you the video afterwards if you come to me. All right. So I'm going to mark this as answered. What about croissant? Is that a rollup? Because we do have one vote over here. Which one? Is a croissant a rollup? Yes. A croissant is a rollup. Yeah. What are some other terms and concepts that need defining? That's a really good question. I think L2 is a hopeless term. So let's not bother with that one at first. But things like bridge is a really easy thing to define. The stages for rollups, right? Stage 0, stage 1, stage 2. I think those things can be defined very, very well, and that would help a lot of people. And kind of just, I mean, honestly, at the end of the day, more than defining new terms, I'd like for the ecosystem to start throwing away terms and redefining things like sovereign roll-up or validium or whatever in terms of these simpler things that we can all agree on. Cool. And these questions, guys. When will I be bleaching my hair again? I don't know. I mean, today, I guess. Why not? Great. I'll bleach my hair today and I'll whatever. Why not? What are some other terms and concepts? We talked about that. Rollups don't use proofs. Bridges use proofs. But rollups use bridges, right? Without a bridge, what distinguishes a rollup from a foreign chain? Well, all chains use bridges, right? The fact that we have bridges is not unique to rollups. The unique thing about rollups is that it allows you to build a special type of bridge that has better security properties than if you just had two completely unrelated chains. But the fact that that's true doesn't mean that that bridge has to be built by the same people that built the rollup and it doesn't mean that you can only have one of these. You don't even have to have any of them if you don't want. Since rollups outsource consensus, does it mean that decentralizing the rollup doesn't make sense? This is kind of a contentious topic. I would say that the correct answer here is that decentralizing the rollup means a different thing than it would on the layer one, because you have most of your security properties, even if you have a centralized block producer or a centralized sequencer, you don't lose liveness, right? Because you can do this special thing between the rollup and the parent chain, and you don't lose safety. And so this is generally why doing stuff like decentralizing the sequencer has been relatively low on the priority list of a lot of rollup teams, because you have very good security properties and you don't really lose much, except for this kind of short-term liveness. Now eventually short-term liveness will become the most critical part. But usually focusing time and effort on the bridges and making those bridges robust takes up more time for people. All right. I guess we have a few more minutes for one more question. How does sharding fit into this? It's what I do on the toilet all day. How does sharding fit into this? I don't know. This is such a confusing question. I could spend a whole minute working on it. I'm going to skip that one. Perfect. All right, we can leave it there. Yeah, great. All right. Great. Thank you, Kevin. Thank you, Kevin. Thank you.",
- "eventId": "devcon-7",
- "slot_start": 1731398400000,
- "slot_end": 1731400200000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1Zq5DAdb9ha3cFF-gOzk6L82ORlY9uvzFl7T5sV1W2mg",
- "resources_slides": null,
"speakers": [
- "kelvin-fichter"
- ]
+ "minh-ho"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731638700000,
+ "slot_end": 1731640500000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1abSiS9Ilz8g4Nc9doFglzH8ruOPatELbzUm3z4IqpRE"
},
"vector": [
+ 6,
0,
0,
0,
@@ -175441,8 +175071,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -176184,6 +175812,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -176228,11 +175858,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 2,
0,
0,
0,
@@ -176252,7 +175877,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -176328,6 +175952,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -176394,6 +176019,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -176747,12 +176373,12 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -176769,49 +176395,38 @@
},
{
"session": {
- "id": "cuevm-gpu-accelerated-evm-for-security-and-beyond",
- "sourceId": "PQBKHF",
- "title": "CuEVM: GPU-Accelerated EVM for Security and Beyond",
- "description": "In this talk, we present CuEVM, an EVM executor implemented in CUDA for running a massive number of transactions in parallel. Its primary application is to accelerate fuzzing by testing transactions in multiple sandbox EVMs on GPUs. Additionally, we have integrated it into Goevmlab to support a broader range of use cases. We will discuss the design choices, challenges, results, and future plans to leverage CuEVM beyond fuzzing.",
- "track": "Security",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "id": "cultivating-culture-in-web3-preserving-the-essence-as-we-evolve",
+ "sourceId": "MZMQXY",
+ "title": "Cultivating Culture in Web3: Preserving the Essence as We Evolve",
+ "description": "Meaningful conversation around the importance of maintaining the unique culture of Ethereum, especially as we continue to grow and attract individuals from traditional backgrounds. The chat can explore how to uphold the values and ethos that have shaped the web3 community + the higher human needs of belonging, connectedness, and purpose etc.\r\n\r\nThis would be between myself and Aya",
+ "track": "Cypherpunk & Privacy",
+ "type": "Panel",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Parallel",
- "EVM"
- ],
- "tags": [
- "Scalability",
- "Security",
- "Fuzzing",
- "EVM",
- "parallel",
- "Fuzzing",
- "Scalability",
- "Security"
+ "culture"
],
+ "tags": [],
"language": "en",
"speakers": [
- "minh-ho"
+ "simona-pop",
+ "aya-miyaguchi"
],
"eventId": "devcon-7",
- "slot_start": 1731638700000,
- "slot_end": 1731640500000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1abSiS9Ilz8g4Nc9doFglzH8ruOPatELbzUm3z4IqpRE"
+ "slot_start": 1731558600000,
+ "slot_end": 1731562200000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/1MEHwnn1XVg3IxqYq8U8Z80rO7dw8-zksCQ9QTwsL6X8"
},
"vector": [
- 6,
- 0,
- 0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -176986,6 +176601,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -177556,8 +177172,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -177696,7 +177310,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -177763,7 +177376,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -177789,7 +177401,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -178117,7 +177728,7 @@
0,
0,
0,
- 2,
+ 0,
0,
0,
0,
@@ -178129,6 +177740,9 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
0,
0,
0,
@@ -178139,30 +177753,47 @@
},
{
"session": {
- "id": "cultivating-culture-in-web3-preserving-the-essence-as-we-evolve",
- "sourceId": "MZMQXY",
- "title": "Cultivating Culture in Web3: Preserving the Essence as We Evolve",
- "description": "Meaningful conversation around the importance of maintaining the unique culture of Ethereum, especially as we continue to grow and attract individuals from traditional backgrounds. The chat can explore how to uphold the values and ethos that have shaped the web3 community + the higher human needs of belonging, connectedness, and purpose etc.\r\n\r\nThis would be between myself and Aya",
- "track": "Cypherpunk & Privacy",
- "type": "Panel",
+ "id": "cultivating-the-understory-building-resilient-daos",
+ "sourceId": "NRHH9B",
+ "title": "Cultivating the Understory : Building Resilient DAOs",
+ "description": "Let's explore the overlooked \"understory\" of DAOs and teams: the human layer that forms the foundation of successful decentralized governance. While much attention is given to the technical and structural aspects of DAOs (the \"overstory\"), we'll dive into the cultural, social, and distributed leadership elements that are crucial for the longevity and effectiveness of anything we build.\r\n\r\nThemes: DAO Ecology, Decentralized leadership, Coding culture DNA, Biomimicry for Governance",
+ "track": "Coordination",
+ "type": "Talk",
"expertise": "Beginner",
"audience": "Community",
- "featured": false,
+ "featured": true,
"doNotRecord": false,
+ "tags": [
+ "Coordination",
+ "DAO",
+ "Vision",
+ "resiliency",
+ "Coordination",
+ "DAO",
+ "Vision"
+ ],
"keywords": [
- "culture"
+ "Culture",
+ "Resilience"
],
- "tags": [],
+ "duration": 1569,
"language": "en",
- "speakers": [
- "simona-pop",
- "aya-miyaguchi"
- ],
+ "sources_swarmHash": "0536080797b46eb6a52445d16070f665d69e68664ce0253bfed99069d746be0d",
+ "sources_youtubeId": "274Uyrxv6uI",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731558600000,
- "slot_end": 1731562200000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/1MEHwnn1XVg3IxqYq8U8Z80rO7dw8-zksCQ9QTwsL6X8"
+ "slot_start": 1731400200000,
+ "slot_end": 1731402000000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/15uqb6bZbGBerAG0KgTCVf2KHzFimQ1D5YSJ8jUna96c",
+ "resources_slides": null,
+ "speakers": [
+ "songyi-lee"
+ ]
},
"vector": [
0,
@@ -178170,13 +177801,13 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -178346,7 +177977,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -179016,6 +178646,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -179069,11 +178700,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -179145,6 +178778,54 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -179427,59 +179108,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -179500,46 +179128,46 @@
},
{
"session": {
- "id": "cultivating-the-understory-building-resilient-daos",
- "sourceId": "NRHH9B",
- "title": "Cultivating the Understory : Building Resilient DAOs",
- "description": "Let's explore the overlooked \"understory\" of DAOs and teams: the human layer that forms the foundation of successful decentralized governance. While much attention is given to the technical and structural aspects of DAOs (the \"overstory\"), we'll dive into the cultural, social, and distributed leadership elements that are crucial for the longevity and effectiveness of anything we build.\r\n\r\nThemes: DAO Ecology, Decentralized leadership, Coding culture DNA, Biomimicry for Governance",
- "track": "Coordination",
- "type": "Talk",
+ "id": "cypherpunk-for-centuries-coordination-and-secrecy-across-the-ages",
+ "sourceId": "NMKQYY",
+ "title": "Cypherpunk for Centuries: Coordination and Secrecy Across the Ages",
+ "description": "Join Evin McMullen for an adventure through the historical ledger, learning from ancient examples of human coordination, governance and selective disclosure technologies whose principles are reflected in the onchain experiences we know and love today. \r\n\r\nPull up a chair, anon. Class is in session, so let’s explore the core Ethereum Values and context in which we live, and what came before us, through the lens of tech that led to the modern cypherpunk movement.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Community",
- "featured": true,
+ "audience": "Product",
+ "featured": false,
"doNotRecord": false,
"tags": [
- "Coordination",
- "DAO",
- "Vision",
- "resiliency",
- "Coordination",
- "DAO",
- "Vision"
+ "Governance",
+ "Network State",
+ "Security",
+ "culture",
+ "Governance",
+ "Network State",
+ "Security"
],
"keywords": [
- "Culture",
- "Resilience"
+ "History",
+ "Culture"
],
- "duration": 1569,
+ "duration": 330,
"language": "en",
- "sources_swarmHash": "0536080797b46eb6a52445d16070f665d69e68664ce0253bfed99069d746be0d",
- "sources_youtubeId": "274Uyrxv6uI",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "XJKbwYhs3j0",
"sources_ipfsHash": "",
"sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
+ "sources_streamethId": "67349ecd9dbb7a90e132caa2",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673499049dbb7a90e1dd0381.vtt",
+ "transcript_text": " 6 p.m. Final slot. Everyone wants to talk at 6 p.m. and also listen to talks at 6 p.m. All right. Well, hello. I am Carl. We're going to talk about interoperability for Ethereum. So defragmenting Ethereum. We are in, let's pick up where we left off. So I really measure time based on DEVCONs. It's like one DEVCON and then two DEVCONs, you know, go that's kind of how I measure it. And I really think it's kind of legit in that every DEVCON there feels like a new sea change that happens. All the brains get together and they mash up. And I feel like DevCon 5, it was this crazy proliferation or this beginning of optimistic roll-ups, ZK roll-ups. And then we had next the super chain and proliferation of all these OP stack chains across Ethereum. And then boom, now we are in a new phase, which I like to call interoperation, because unfortunately with the proliferation phase, you end up with a whole bunch of fragmentation. But this is exciting. We have a moment where we literally have an unbelievable amount of low-hanging fruit to bring all of these chains together through open source interoperability standards across Ethereum. So nothing is that new, by the way. This is a PSA, people. Nothing is that new. Nothing is that unexpected. And technology marches forward very, very slowly. In other words, we've known about all of these problems since the, you know, scaling roadmap for Ethereum that Vitalik put out way too many years ago. And, you know, sometimes I think of myself as like a little snail moving along, like seeing the tech progress go. And then I whip out my phone and I'm like, oh my God, what's going on? And I'm on the moon. But no, it's fake news. Just calm down. We're making progress one step at a time. So, you know, right? Like, we knew that we would have a bunch of chains, and we'd fragment the roll-ups, and then we'd, you know, join them together into a happy union. Like, that's kind of, That's been the point. So, anyway, I want to talk about the basically my goal for this talk is to show a very large amount of, you know, low hanging fruit that we can all pluck for this interoperability phase. And, you know, before even all of these dev cons, I was but a mere durable developer working on memes of meme craft. You know, my absolutely killer application. It was incredible. You know, I had everything that you needed for a killer app in Ethereum, right? I had a manifesto. I had a team page. And I even had an unusable application. It was like literally killer app material. But I knew that there was one thing that would hold me back and that was my application would never scale to the number of users that I needed. I knew the world was going to use memes of meme craft. 10 TPS, you know, 10 second latency, not going to make it. And so I got into the trenches. We all got into the trenches and we started building out both the role of technology and now the interoperability technology to make it possible. And so it really is a moment where it has become possible. The low-hanging fruit is immense. So let's go over kind of like all a smathering, a kind of shotgun of all the different things that we need to fix, candidly, to make this happen. Things, by the way, that are not new. Like the great thing about this low-hanging fruit is that it has been done before. For example, asynchronous programming paradigms, that is the norm in normal application development. We can build those in. Passkeys, thankfully, Web2 did us a solid and fixed a bunch of our wallet UX for us. Sessions, like session keys for when I log into a website and I do a bunch of interactions without constantly clicking sign transaction over and over and over again. There's no reason that this stuff and more cannot be used in the crypto space. So in order to kind of like make this a little bit more tangible, I'm going to go through a user journey, kind of a developer journey, and then just like talk more about the tech. So let's get into the user journey. What is the user journey of memes of meme craft? This incredible application for the masses, right? We're gonna have a login screen. The login screen, familiar terms. We're talking about logging in. No seed phrases, pass keys, I'm sorry. I just have to, we need decentralization but we just got to make it usable at the same time. So both, both mass adoption and decentralization, but we just got to make it usable at the same time. So both mass adoption and decentralization for the world. So, you know, click login, sign in with a passkey, user auth with face ID, boom, you're in. Great. Now the next stage, mint. We need to, of course, mint our memes. So what do I need to do? I need to click on mint. No extra signature, just like boom, transaction succeeded in the background. Don't worry about it. Easy. Now I have my memes, and now I'm going to battle them. Of course, what else would you do with your memes? So I'm going to matchmake. Boom, I found a battle match person. And success, I won. Right? Great. And now, of course, I'm going to share my battle. Because that's what we miss about Web 2 and Web 3, the ability to click the share button. I've never clicked the share button, unfortunately. But anyway, really I just wanted to talk about composability. And that was my little segue into it. So simple, right? That was like a very normal, like, honestly incredibly boring user flow, unfortunately. Well, no, no, no. It's a great user flow. Memes of Minecraft, take it off. But the developer journey is actually kind of immense to make all that happen while preserving the open source decentralized protocols that we all know and love. So, developer journey, building all these things. Okay, first, I'm going to kind of skip past a bunch of the developer journey because it's not actually just too much. But imagine we're on an AI code editor and in the browser with auto-refresh and all the bells and whistles. OK, so for the login side of things, we're going to sign in. OK, what do we need here? Well, we need easy to use frontend libraries that I can just very easily import, start a passkey kind of session, smart wallets with sessions or even just a temporary wallet, that's fine by me. A super RPC so that I can actually send transactions to all of these different chains. I don't need to click on that network switching, kind of icon. All of this built in very seamlessly. Please give me a very good solution for this. All the chains across Ethereum, you know, let's do it. So, right, clicked mint, etc. Now, this little flow, this little flow is actually insanely challenging. So, what happened here? First off, I have assets across a whole bunch of chains. I clicked mint, and I paid for gas. I paid for the mint of that meme. And I did not have to worry about any of these silly chains. Why did I not have to worry? Because we got things like ERC7683, the easiest ERC to say. And what that is, is intense. You're able to abstract away and say, okay, a user has cash on, you know, one chain, one ecosystem. There's a really high latency bridge that connects them. Well, happens to be that there's an open protocol for fast liquidity providers that you can send them your capital on this chain, and then boom, they will give you the same amount on the destination chain. No problem. They'll handle rebalancing. And this is great. It's a win-win for everyone. Instant user experience for the user and fees for the liquidity providers, regardless of the speed of your message passing. Now, this, and we can get a good UX for this too, you know, abstracted into a very simple interface that everyone can use. All right. So first off, that's how we consolidate all the assets into one chain. But obviously, because my example has this in it, the mint function is on a different chain. So what did I do? Well, I wrote an asynchronous smart contract. So, you know, we're building out these interoperability protocols. If you use a kind of like, you know, intertwinement-based interop protocol, then you can achieve two-second or really instant interoperability. And that is a major unlock because now developers across the Ethereum ecosystem, it's one thing to build a smart contract that does a kind of, you know, end to end two chain flow with, you know, when you have to wait for like, you know, even five minutes is a long time. But if it's just an instant flow between the chains, that's like, I don't know, I personally experienced it. You will too, and it's pretty sick. Anyway, so we can actually build out a whole bunch of asynchronous programming libraries pretty easily even today. You can use common promise syntax that you'll be familiar with if you, you know, do, for example, JavaScript. And promise sponsorship, you know, we are going to be able to reuse all of this intent-based infrastructure for general messages. And by the way, Ben wrote an async, you know, library, and Ben is not even like, well, he's a physicist. He's not some coding genius. He wrote it in three days. You know what I mean? This is like, this is the level of like obvious stuff. You don't have to be smart to be like, oh, JavaScript has solved this problem this way, and it's not solved in my language, let me just do that. You know what I mean? Like, that's the kind of problem that I like, you know? Because I can't think of smart things generally. That's hard. Okay. So, anyway. Battling, right? We're going to battle. Matchmaking. Boop, boop, boop. Found. All right. Remember, that's what happened. What happened in the background? Well, what did we do first off? We found a low congestion chain because guess what battling is transaction intensive, of course Do a lot of battles anyway and they're gonna be chains that have high liquidity that will always have high fees because there's an incentive if the price moves and you Need to our bidding you got a bunch bots, you get a bunch of spam. Well, you need some chains that are explicitly not going to be the mega TVL chains that can do your little battles, you know? And you also probably want to have subsets of chains that you interact with explicitly. For example, memes of MemeCraft actually has two chains, and one of them is kind of medium usage and one of them is low. And so the front end will automatically just check and see, okay, the gas fees are very low on this chain. Let me deploy the battler there. Speaking of deploying the battler, installing contracts. This is 100% like, you know, contract deployment should be permissionless by default. And then developers can restrict where they want their contracts to live. This ecosystem, that ecosystem, this chain, that chain. But for a large swath of public good contracts, for example, you really want to have that be available as many places as possible. And so, you know, instead of just developers having to, like, choose where to deploy, the front-end should just deploy directly, and we can do that with Create2 Factory, which is available on, like, pretty much all the EVM chains. Cool. So... Now on to the bragging section. Well, this is... Obviously, I added this, tacked this in, because I really wanted to talk about composability and chill a very particular concept That is you know a little crazy, but think about it composability is key web 3 composability That is like the magic sauce. What is the most analogous, you know composable first thing? My opinion it is the web browser The web browser is this amazing universe where all these? Websites can link to each other and use each other and all that stuff and what did they do? They made this crazy choice the people who did the smart things over there in the web browser they decided to literally send code instead of just like binary blobs over the wire to then display in the browser. What did that do? This was an intentional choice by the web browser developers. They wanted to make it so that users, anyone, can right-click, inspect element, and read the code that runs and powers their website. Kind of sound familiar? Well, turns out we are doing the same thing all the time. We're just going to Etherscan and then getting very frustrated that the contract has not been verified yet. And then we're like, how do I verify it? And it's horrible. So anyway, I'm just really, I think we can like 10x the amount of, you know, code collaboration and the speed of our feedback cycles if we have things like on-chain package managers or inspect element for smart contracts, some kind of environment that makes coding with smart contracts more collaborative. Now, obviously, you know, maybe it doesn't work for a crazy DeFi protocol you want to formally verify, but I just think smart contract programming can be so fun. It doesn't need to be a horrible mess. And I don't know, we just haven't invested. So let's invest and make the feedback cycles fast and make it so that it's easy to learn because there's tons of examples of how people are doing it. And we can really foster an open source culture, not just at the protocol layer, but also at the smart contract layer. So now that was a kind of developer kind of shotgun of all the tech. Let me just list it all out in one big list. So first off, right, cross-chain reads and messaging. I could do a whole talk on this one. I'm not going to get into too many deets. But the TLDR of these and by the way, this is all open source protocols. There is no this is just a fact of the universe basically that you can build interoperability protocols which use this kind of optimistic or speculative output. So you're on one chain and you're like, okay, I think that this other chain is going to resolve to this value. So I will optimistically include that value and then move forward. And this works for ZKP-based proofs and TE-based proofs and all sorts of proofs. It's just literally, it's kind of, you know, how we, you know, lowered the latency of L2s by introducing a sequencer and more predictability in the ordering before it hits Ethereum. Same kind of, same kind of thing. So anyway, Mark can tell you, Proto can tell you more about that. And then, of course, we got Intents that, you know, There have been many talks. Shout out to Hart from before. Also, of course, chain-specific configs and chain-specific addresses all on L1 so that we can deterministically derive all of these different chains from Ethereum. Super important. Also, cross-chain token standard. Very exciting. All of these people, We can have interoperable tokens with zero slippage liquidity. And we've got this is my favorite section because it's the essentials. It's obvious. We need to build this. And it's just badly supported now. So like promise libraries that hook into Solidity as it is today, or even modifications to Viper Solidity that support promises better, please, please. And then also async contract upgrades is going to be a whole thing. Oh, my God. If you want to build the new open Zeppelin thing, man, there is going to be real patterns that develop there. And we need to standardize what those async upgrade patterns look like. I already talked about how users should be able to install contracts on chains. That is enabled with these create to deployments. You're able to permissionlessly deploy a contract at a particular address and not mess with the configs. And passkey wallets. We need to solve user experience. And so then, of course, finally the dream section. I just really want this collaborative coding environment. It would be so nice. Also all VMs, shout out to all the VMs. And write some rust or whatever. Oracleize everything. I want all these RPC requests to come with signatures so that I can use literally just use them for whatever. If I'm really horrible, I can do an RPC request and use that as a bridge for my horrible degenerate token bridge thing. Definitely probably don't do that. Missed browser. Okay, no. That one is a little... I'm going to get some flack for that one. But I don't know. I just still want to, like, not have to rely on a central party and load up a decentralized website, like, fully deterministically. I don't know. And obviously, you know, that's kind of the point of the dream section. I don't know everything. So, you know, we are this little slow snail progressing through the technological thing. And sometimes we come upon a tree and a whole bunch of fruit. And you know what? In those moments, those are the moments to capture and just absolutely devour all that low-hanging fruit because it is, I mean, it's easy. And I will say that I was last week, shout out to Proto, shout out to Mark, shout out to the interop, like peeps, they put together this interop devnet and I was like playing with it and it really felt like 2016 again. I don't know, this is such a reminiscing talk for me, I don't know why. It felt like 2016 again, where like everything is so obvious that needs to be built, and yet no one has built it because no one actually, I don't know, has like, I don't know, done it yet. And it's just, it was exciting. It was exciting. Like all the pieces coming together. It's like more collaborative because you're, because you're not fighting over a tiny little slice of a pie. You're like, oh, I'm going to work on this, and then you're going to work on that, and we can compose together, and we'll all win together. I mean, that is how we unify Ethereum IMO. And finally, create memes of meme craft. So this is our timeline. But what about DEF CON 8? Well, DEF CON 8, it is mass adoption time. We're going to have 8 billion users. Ethereum is going to solve the fertility crisis. Can't stop until global adoption. Every single person. And so, obviously, you know, very excited for the future. But we still got a lot of things to do. We got to ship Interop, obviously. All these standards. We got to scale ETHDA. We got to dog food the protocol. We got to build all these dev tools. And hopefully, either is Phoenix willing, you know, we'll be able to unify Ethereum, defragment Ethereum, I guess is what I should have been saying, create a retroactive public goods flywheel so that we're funding open source software from now into the future. And, you know, that's why we're building the Optimism Collective. Together, we can make impact equals profit and summon ETHUS Phoenix, build a user-owned internet. Thank you very much. All right, Carl. You know, when I was watching him perform I was reminded of someone who moves a lot And so much energy And it was such a joy watching you do that presentation When someone is so passionate about something You cannot help but smile And the first and most popular question Carl is How does Carl have so much energy? Because I'm deeply anxious And I channel it into excitement. What a gently answer. I'm deeply anxious. Okay, anyway, moving on to the other questions. Thank you for that lovely question. Carl, if I were to start building a library or framework today to make building horizontally scalable apps as possible what should I build? Nice okay if you are a solidity nerd then go out compete Ben because you definitely will have just kidding and build an async promise library something like that no the other thing if you want to just be I don't know key to my heart I built a horrible like create two base deployer thing. I just want to make create two deployments really easy because, I don't know, I just don't like dealing with the, I don't know, it's just the tooling is bad. You know, please, please do help me with that. Yeah, those are two of them. And the slides have even more. Fantastic. Please do help me with that. Those are two of them. And the slides have even more. Fantastic. When will Optimism Mainnet become a ZK roll-up? We already have! Obviously, Optimism is the name. We're very optimistic people. We obviously love optimistic designs. But, notably, Optimism is not a ZK roll-up. Not an optimistic roll-up. It's actually not really. It's a super chain. But the tech, the OP stack supports all types of proofs. And in fact, one of our design principles is to be proof agnostic so that we don't need to choose between this proof or that proof, and instead we can use them all. Because to be honest, they're all really bad. So when you have a lot of bad things, you stack them on top of each other and hope that nothing, well, they all don't break at the same time. That's called multi-proof, by the way. It's not just trolling. You have got to be the most entertaining speaker I've ever had to MC for. Isn't Superchain kind of like vendor lock-in? What would you say to that? I mean, I think there is, you know, definitely an aspect, but what are you getting locked into is my question. You are getting, quote-unquote, locked into open source protocols which fund public goods and, you know, create a flywheel that hopefully we all benefit from. And guess what? Ethereum, I don't know. Okay, they're going to get mad at me. But anyway. No. I think you can fork everything. You know? Fork us. And by the way, actually fork friendly is in our constitution and in everything that we do. It is incredibly important that it's open source so that you can, if you get vendor locked in in a bad way, fork to a different system. By the way, way, another thing. Web3, the whole point of Web3 is enabling a somewhat more robust right-to-voice. Vendor lock-in is inevitable in some sense and that is why in Web2 this whole like just exit this platform for the other platform, we see it doesn't work. Instead what we need to do is we need to build systems where governance represents the constituent parties and so that's what we're trying to do. we need to build systems where governance represents the constituent parties. So that's what we're trying to do. Very good. We got one and a half minutes. Excellent answer. One and a half minutes. Let's see how many questions we can go through. Which are the key things Dream Interop has to have? We want it to be fast, trustless, and secure. No. But, okay, yes. 100% fast. Honestly, yeah, fast, trustless, and secure. But for real, fast was my, like, I honestly undervalued the fast thing until I started using the fast thing. I got a little addicted. Because, like, there's a very big difference if you, like, have to go, like, if it's more than a couple seconds, then I'm going to click to a different web page. And I hate, like, I'm never going to go back. And so, I don't know, when I started, even when I'm testing, it's so much nicer to be able to, like, do everything real quick. So fast, really fast. Sub-cent and sub-second. Cheap, I guess, is the first thing I forgot to say. All right. We've got 20 seconds. You want to do one more? Last one. What are the biggest mistakes the Ethereum ecosystem risks making as it works on interrupt? Making it work on interrupt risks? Well, okay, I don't know what that actually means, and I'm not good at reading, and so I can't figure it out. But what I'm going to say is the biggest risk for Ethereum is to forget our values. We are building open source protocols that will create the world computer. There is one world computer. We're all building it. Remember that we can do this together. Don't, you know, get too mad at each other. It's fine. The algorithms don't control us. Well, that was truly the most entertaining Q&A I've ever hosted. Let's give him a big round of applause. Carl!",
"eventId": "devcon-7",
- "slot_start": 1731400200000,
- "slot_end": 1731402000000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/15uqb6bZbGBerAG0KgTCVf2KHzFimQ1D5YSJ8jUna96c",
+ "slot_start": 1731493800000,
+ "slot_end": 1731494400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1zKy1Wacd_g6VIy9gBPNTLczV1UoUIzGVToCNnN39u1c",
"resources_slides": null,
"speakers": [
- "songyi-lee"
+ "evin-mcmullen"
]
},
"vector": [
@@ -179548,16 +179176,13 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -179692,6 +179317,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -179750,7 +179376,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -180295,6 +179920,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -180341,6 +179967,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -180389,6 +180016,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -180396,7 +180024,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -180450,13 +180077,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -180864,7 +180489,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -180873,51 +180497,48 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "cypherpunk-for-centuries-coordination-and-secrecy-across-the-ages",
- "sourceId": "NMKQYY",
- "title": "Cypherpunk for Centuries: Coordination and Secrecy Across the Ages",
- "description": "Join Evin McMullen for an adventure through the historical ledger, learning from ancient examples of human coordination, governance and selective disclosure technologies whose principles are reflected in the onchain experiences we know and love today. \r\n\r\nPull up a chair, anon. Class is in session, so let’s explore the core Ethereum Values and context in which we live, and what came before us, through the lens of tech that led to the modern cypherpunk movement.",
+ "id": "cypherpunk-is-slow-not-hyper-financialized-and-unlike-twitter",
+ "sourceId": "QPQZJR",
+ "title": "Cypherpunk is slow, not hyper-financialized and unlike Twitter",
+ "description": "In this lightning talk I will present three major directions that we need to tackle to make Ethereum Cypherpunk:\r\n1. Against popular trends, I call for increasing block time (instead of making it faster) to increase resilience via better DVT and mixnets - both are struggling with low latency blocks\r\n2. Let's revive the Ethereum world computer, not just financial infrastructure and their implications\r\n3. Rethink [d]app UX entirely - how does resilient human interaction feel like in the digital era?",
"track": "Cypherpunk & Privacy",
"type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"tags": [
- "Governance",
- "Network State",
- "Security",
- "culture",
- "Governance",
- "Network State",
- "Security"
+ "latency",
+ "Censorship Resistance",
+ "Ethereum Roadmap",
+ "Not financial"
],
"keywords": [
- "History",
- "Culture"
+ "Latency"
],
- "duration": 330,
+ "duration": 467,
"language": "en",
"sources_swarmHash": "",
- "sources_youtubeId": "XJKbwYhs3j0",
+ "sources_youtubeId": "ngz-Zug_LS8",
"sources_ipfsHash": "",
"sources_livepeerId": "",
- "sources_streamethId": "67349ecd9dbb7a90e132caa2",
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673499049dbb7a90e1dd0381.vtt",
- "transcript_text": " 6 p.m. Final slot. Everyone wants to talk at 6 p.m. and also listen to talks at 6 p.m. All right. Well, hello. I am Carl. We're going to talk about interoperability for Ethereum. So defragmenting Ethereum. We are in, let's pick up where we left off. So I really measure time based on DEVCONs. It's like one DEVCON and then two DEVCONs, you know, go that's kind of how I measure it. And I really think it's kind of legit in that every DEVCON there feels like a new sea change that happens. All the brains get together and they mash up. And I feel like DevCon 5, it was this crazy proliferation or this beginning of optimistic roll-ups, ZK roll-ups. And then we had next the super chain and proliferation of all these OP stack chains across Ethereum. And then boom, now we are in a new phase, which I like to call interoperation, because unfortunately with the proliferation phase, you end up with a whole bunch of fragmentation. But this is exciting. We have a moment where we literally have an unbelievable amount of low-hanging fruit to bring all of these chains together through open source interoperability standards across Ethereum. So nothing is that new, by the way. This is a PSA, people. Nothing is that new. Nothing is that unexpected. And technology marches forward very, very slowly. In other words, we've known about all of these problems since the, you know, scaling roadmap for Ethereum that Vitalik put out way too many years ago. And, you know, sometimes I think of myself as like a little snail moving along, like seeing the tech progress go. And then I whip out my phone and I'm like, oh my God, what's going on? And I'm on the moon. But no, it's fake news. Just calm down. We're making progress one step at a time. So, you know, right? Like, we knew that we would have a bunch of chains, and we'd fragment the roll-ups, and then we'd, you know, join them together into a happy union. Like, that's kind of, That's been the point. So, anyway, I want to talk about the basically my goal for this talk is to show a very large amount of, you know, low hanging fruit that we can all pluck for this interoperability phase. And, you know, before even all of these dev cons, I was but a mere durable developer working on memes of meme craft. You know, my absolutely killer application. It was incredible. You know, I had everything that you needed for a killer app in Ethereum, right? I had a manifesto. I had a team page. And I even had an unusable application. It was like literally killer app material. But I knew that there was one thing that would hold me back and that was my application would never scale to the number of users that I needed. I knew the world was going to use memes of meme craft. 10 TPS, you know, 10 second latency, not going to make it. And so I got into the trenches. We all got into the trenches and we started building out both the role of technology and now the interoperability technology to make it possible. And so it really is a moment where it has become possible. The low-hanging fruit is immense. So let's go over kind of like all a smathering, a kind of shotgun of all the different things that we need to fix, candidly, to make this happen. Things, by the way, that are not new. Like the great thing about this low-hanging fruit is that it has been done before. For example, asynchronous programming paradigms, that is the norm in normal application development. We can build those in. Passkeys, thankfully, Web2 did us a solid and fixed a bunch of our wallet UX for us. Sessions, like session keys for when I log into a website and I do a bunch of interactions without constantly clicking sign transaction over and over and over again. There's no reason that this stuff and more cannot be used in the crypto space. So in order to kind of like make this a little bit more tangible, I'm going to go through a user journey, kind of a developer journey, and then just like talk more about the tech. So let's get into the user journey. What is the user journey of memes of meme craft? This incredible application for the masses, right? We're gonna have a login screen. The login screen, familiar terms. We're talking about logging in. No seed phrases, pass keys, I'm sorry. I just have to, we need decentralization but we just got to make it usable at the same time. So both, both mass adoption and decentralization, but we just got to make it usable at the same time. So both mass adoption and decentralization for the world. So, you know, click login, sign in with a passkey, user auth with face ID, boom, you're in. Great. Now the next stage, mint. We need to, of course, mint our memes. So what do I need to do? I need to click on mint. No extra signature, just like boom, transaction succeeded in the background. Don't worry about it. Easy. Now I have my memes, and now I'm going to battle them. Of course, what else would you do with your memes? So I'm going to matchmake. Boom, I found a battle match person. And success, I won. Right? Great. And now, of course, I'm going to share my battle. Because that's what we miss about Web 2 and Web 3, the ability to click the share button. I've never clicked the share button, unfortunately. But anyway, really I just wanted to talk about composability. And that was my little segue into it. So simple, right? That was like a very normal, like, honestly incredibly boring user flow, unfortunately. Well, no, no, no. It's a great user flow. Memes of Minecraft, take it off. But the developer journey is actually kind of immense to make all that happen while preserving the open source decentralized protocols that we all know and love. So, developer journey, building all these things. Okay, first, I'm going to kind of skip past a bunch of the developer journey because it's not actually just too much. But imagine we're on an AI code editor and in the browser with auto-refresh and all the bells and whistles. OK, so for the login side of things, we're going to sign in. OK, what do we need here? Well, we need easy to use frontend libraries that I can just very easily import, start a passkey kind of session, smart wallets with sessions or even just a temporary wallet, that's fine by me. A super RPC so that I can actually send transactions to all of these different chains. I don't need to click on that network switching, kind of icon. All of this built in very seamlessly. Please give me a very good solution for this. All the chains across Ethereum, you know, let's do it. So, right, clicked mint, etc. Now, this little flow, this little flow is actually insanely challenging. So, what happened here? First off, I have assets across a whole bunch of chains. I clicked mint, and I paid for gas. I paid for the mint of that meme. And I did not have to worry about any of these silly chains. Why did I not have to worry? Because we got things like ERC7683, the easiest ERC to say. And what that is, is intense. You're able to abstract away and say, okay, a user has cash on, you know, one chain, one ecosystem. There's a really high latency bridge that connects them. Well, happens to be that there's an open protocol for fast liquidity providers that you can send them your capital on this chain, and then boom, they will give you the same amount on the destination chain. No problem. They'll handle rebalancing. And this is great. It's a win-win for everyone. Instant user experience for the user and fees for the liquidity providers, regardless of the speed of your message passing. Now, this, and we can get a good UX for this too, you know, abstracted into a very simple interface that everyone can use. All right. So first off, that's how we consolidate all the assets into one chain. But obviously, because my example has this in it, the mint function is on a different chain. So what did I do? Well, I wrote an asynchronous smart contract. So, you know, we're building out these interoperability protocols. If you use a kind of like, you know, intertwinement-based interop protocol, then you can achieve two-second or really instant interoperability. And that is a major unlock because now developers across the Ethereum ecosystem, it's one thing to build a smart contract that does a kind of, you know, end to end two chain flow with, you know, when you have to wait for like, you know, even five minutes is a long time. But if it's just an instant flow between the chains, that's like, I don't know, I personally experienced it. You will too, and it's pretty sick. Anyway, so we can actually build out a whole bunch of asynchronous programming libraries pretty easily even today. You can use common promise syntax that you'll be familiar with if you, you know, do, for example, JavaScript. And promise sponsorship, you know, we are going to be able to reuse all of this intent-based infrastructure for general messages. And by the way, Ben wrote an async, you know, library, and Ben is not even like, well, he's a physicist. He's not some coding genius. He wrote it in three days. You know what I mean? This is like, this is the level of like obvious stuff. You don't have to be smart to be like, oh, JavaScript has solved this problem this way, and it's not solved in my language, let me just do that. You know what I mean? Like, that's the kind of problem that I like, you know? Because I can't think of smart things generally. That's hard. Okay. So, anyway. Battling, right? We're going to battle. Matchmaking. Boop, boop, boop. Found. All right. Remember, that's what happened. What happened in the background? Well, what did we do first off? We found a low congestion chain because guess what battling is transaction intensive, of course Do a lot of battles anyway and they're gonna be chains that have high liquidity that will always have high fees because there's an incentive if the price moves and you Need to our bidding you got a bunch bots, you get a bunch of spam. Well, you need some chains that are explicitly not going to be the mega TVL chains that can do your little battles, you know? And you also probably want to have subsets of chains that you interact with explicitly. For example, memes of MemeCraft actually has two chains, and one of them is kind of medium usage and one of them is low. And so the front end will automatically just check and see, okay, the gas fees are very low on this chain. Let me deploy the battler there. Speaking of deploying the battler, installing contracts. This is 100% like, you know, contract deployment should be permissionless by default. And then developers can restrict where they want their contracts to live. This ecosystem, that ecosystem, this chain, that chain. But for a large swath of public good contracts, for example, you really want to have that be available as many places as possible. And so, you know, instead of just developers having to, like, choose where to deploy, the front-end should just deploy directly, and we can do that with Create2 Factory, which is available on, like, pretty much all the EVM chains. Cool. So... Now on to the bragging section. Well, this is... Obviously, I added this, tacked this in, because I really wanted to talk about composability and chill a very particular concept That is you know a little crazy, but think about it composability is key web 3 composability That is like the magic sauce. What is the most analogous, you know composable first thing? My opinion it is the web browser The web browser is this amazing universe where all these? Websites can link to each other and use each other and all that stuff and what did they do? They made this crazy choice the people who did the smart things over there in the web browser they decided to literally send code instead of just like binary blobs over the wire to then display in the browser. What did that do? This was an intentional choice by the web browser developers. They wanted to make it so that users, anyone, can right-click, inspect element, and read the code that runs and powers their website. Kind of sound familiar? Well, turns out we are doing the same thing all the time. We're just going to Etherscan and then getting very frustrated that the contract has not been verified yet. And then we're like, how do I verify it? And it's horrible. So anyway, I'm just really, I think we can like 10x the amount of, you know, code collaboration and the speed of our feedback cycles if we have things like on-chain package managers or inspect element for smart contracts, some kind of environment that makes coding with smart contracts more collaborative. Now, obviously, you know, maybe it doesn't work for a crazy DeFi protocol you want to formally verify, but I just think smart contract programming can be so fun. It doesn't need to be a horrible mess. And I don't know, we just haven't invested. So let's invest and make the feedback cycles fast and make it so that it's easy to learn because there's tons of examples of how people are doing it. And we can really foster an open source culture, not just at the protocol layer, but also at the smart contract layer. So now that was a kind of developer kind of shotgun of all the tech. Let me just list it all out in one big list. So first off, right, cross-chain reads and messaging. I could do a whole talk on this one. I'm not going to get into too many deets. But the TLDR of these and by the way, this is all open source protocols. There is no this is just a fact of the universe basically that you can build interoperability protocols which use this kind of optimistic or speculative output. So you're on one chain and you're like, okay, I think that this other chain is going to resolve to this value. So I will optimistically include that value and then move forward. And this works for ZKP-based proofs and TE-based proofs and all sorts of proofs. It's just literally, it's kind of, you know, how we, you know, lowered the latency of L2s by introducing a sequencer and more predictability in the ordering before it hits Ethereum. Same kind of, same kind of thing. So anyway, Mark can tell you, Proto can tell you more about that. And then, of course, we got Intents that, you know, There have been many talks. Shout out to Hart from before. Also, of course, chain-specific configs and chain-specific addresses all on L1 so that we can deterministically derive all of these different chains from Ethereum. Super important. Also, cross-chain token standard. Very exciting. All of these people, We can have interoperable tokens with zero slippage liquidity. And we've got this is my favorite section because it's the essentials. It's obvious. We need to build this. And it's just badly supported now. So like promise libraries that hook into Solidity as it is today, or even modifications to Viper Solidity that support promises better, please, please. And then also async contract upgrades is going to be a whole thing. Oh, my God. If you want to build the new open Zeppelin thing, man, there is going to be real patterns that develop there. And we need to standardize what those async upgrade patterns look like. I already talked about how users should be able to install contracts on chains. That is enabled with these create to deployments. You're able to permissionlessly deploy a contract at a particular address and not mess with the configs. And passkey wallets. We need to solve user experience. And so then, of course, finally the dream section. I just really want this collaborative coding environment. It would be so nice. Also all VMs, shout out to all the VMs. And write some rust or whatever. Oracleize everything. I want all these RPC requests to come with signatures so that I can use literally just use them for whatever. If I'm really horrible, I can do an RPC request and use that as a bridge for my horrible degenerate token bridge thing. Definitely probably don't do that. Missed browser. Okay, no. That one is a little... I'm going to get some flack for that one. But I don't know. I just still want to, like, not have to rely on a central party and load up a decentralized website, like, fully deterministically. I don't know. And obviously, you know, that's kind of the point of the dream section. I don't know everything. So, you know, we are this little slow snail progressing through the technological thing. And sometimes we come upon a tree and a whole bunch of fruit. And you know what? In those moments, those are the moments to capture and just absolutely devour all that low-hanging fruit because it is, I mean, it's easy. And I will say that I was last week, shout out to Proto, shout out to Mark, shout out to the interop, like peeps, they put together this interop devnet and I was like playing with it and it really felt like 2016 again. I don't know, this is such a reminiscing talk for me, I don't know why. It felt like 2016 again, where like everything is so obvious that needs to be built, and yet no one has built it because no one actually, I don't know, has like, I don't know, done it yet. And it's just, it was exciting. It was exciting. Like all the pieces coming together. It's like more collaborative because you're, because you're not fighting over a tiny little slice of a pie. You're like, oh, I'm going to work on this, and then you're going to work on that, and we can compose together, and we'll all win together. I mean, that is how we unify Ethereum IMO. And finally, create memes of meme craft. So this is our timeline. But what about DEF CON 8? Well, DEF CON 8, it is mass adoption time. We're going to have 8 billion users. Ethereum is going to solve the fertility crisis. Can't stop until global adoption. Every single person. And so, obviously, you know, very excited for the future. But we still got a lot of things to do. We got to ship Interop, obviously. All these standards. We got to scale ETHDA. We got to dog food the protocol. We got to build all these dev tools. And hopefully, either is Phoenix willing, you know, we'll be able to unify Ethereum, defragment Ethereum, I guess is what I should have been saying, create a retroactive public goods flywheel so that we're funding open source software from now into the future. And, you know, that's why we're building the Optimism Collective. Together, we can make impact equals profit and summon ETHUS Phoenix, build a user-owned internet. Thank you very much. All right, Carl. You know, when I was watching him perform I was reminded of someone who moves a lot And so much energy And it was such a joy watching you do that presentation When someone is so passionate about something You cannot help but smile And the first and most popular question Carl is How does Carl have so much energy? Because I'm deeply anxious And I channel it into excitement. What a gently answer. I'm deeply anxious. Okay, anyway, moving on to the other questions. Thank you for that lovely question. Carl, if I were to start building a library or framework today to make building horizontally scalable apps as possible what should I build? Nice okay if you are a solidity nerd then go out compete Ben because you definitely will have just kidding and build an async promise library something like that no the other thing if you want to just be I don't know key to my heart I built a horrible like create two base deployer thing. I just want to make create two deployments really easy because, I don't know, I just don't like dealing with the, I don't know, it's just the tooling is bad. You know, please, please do help me with that. Yeah, those are two of them. And the slides have even more. Fantastic. Please do help me with that. Those are two of them. And the slides have even more. Fantastic. When will Optimism Mainnet become a ZK roll-up? We already have! Obviously, Optimism is the name. We're very optimistic people. We obviously love optimistic designs. But, notably, Optimism is not a ZK roll-up. Not an optimistic roll-up. It's actually not really. It's a super chain. But the tech, the OP stack supports all types of proofs. And in fact, one of our design principles is to be proof agnostic so that we don't need to choose between this proof or that proof, and instead we can use them all. Because to be honest, they're all really bad. So when you have a lot of bad things, you stack them on top of each other and hope that nothing, well, they all don't break at the same time. That's called multi-proof, by the way. It's not just trolling. You have got to be the most entertaining speaker I've ever had to MC for. Isn't Superchain kind of like vendor lock-in? What would you say to that? I mean, I think there is, you know, definitely an aspect, but what are you getting locked into is my question. You are getting, quote-unquote, locked into open source protocols which fund public goods and, you know, create a flywheel that hopefully we all benefit from. And guess what? Ethereum, I don't know. Okay, they're going to get mad at me. But anyway. No. I think you can fork everything. You know? Fork us. And by the way, actually fork friendly is in our constitution and in everything that we do. It is incredibly important that it's open source so that you can, if you get vendor locked in in a bad way, fork to a different system. By the way, way, another thing. Web3, the whole point of Web3 is enabling a somewhat more robust right-to-voice. Vendor lock-in is inevitable in some sense and that is why in Web2 this whole like just exit this platform for the other platform, we see it doesn't work. Instead what we need to do is we need to build systems where governance represents the constituent parties and so that's what we're trying to do. we need to build systems where governance represents the constituent parties. So that's what we're trying to do. Very good. We got one and a half minutes. Excellent answer. One and a half minutes. Let's see how many questions we can go through. Which are the key things Dream Interop has to have? We want it to be fast, trustless, and secure. No. But, okay, yes. 100% fast. Honestly, yeah, fast, trustless, and secure. But for real, fast was my, like, I honestly undervalued the fast thing until I started using the fast thing. I got a little addicted. Because, like, there's a very big difference if you, like, have to go, like, if it's more than a couple seconds, then I'm going to click to a different web page. And I hate, like, I'm never going to go back. And so, I don't know, when I started, even when I'm testing, it's so much nicer to be able to, like, do everything real quick. So fast, really fast. Sub-cent and sub-second. Cheap, I guess, is the first thing I forgot to say. All right. We've got 20 seconds. You want to do one more? Last one. What are the biggest mistakes the Ethereum ecosystem risks making as it works on interrupt? Making it work on interrupt risks? Well, okay, I don't know what that actually means, and I'm not good at reading, and so I can't figure it out. But what I'm going to say is the biggest risk for Ethereum is to forget our values. We are building open source protocols that will create the world computer. There is one world computer. We're all building it. Remember that we can do this together. Don't, you know, get too mad at each other. It's fine. The algorithms don't control us. Well, that was truly the most entertaining Q&A I've ever hosted. Let's give him a big round of applause. Carl!",
+ "sources_streamethId": "67349e5c9dbb7a90e13140a5",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67349e5c9dbb7a90e13140a5.vtt",
+ "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you",
"eventId": "devcon-7",
- "slot_start": 1731493800000,
- "slot_end": 1731494400000,
+ "slot_start": 1731493200000,
+ "slot_end": 1731493800000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1zKy1Wacd_g6VIy9gBPNTLczV1UoUIzGVToCNnN39u1c",
+ "resources_presentation": "https://docs.google.com/presentation/d/1oHb6j9HUcr5SBg9cKc9eUxdiZdwushIlE08dKhrQ1zE",
"resources_slides": null,
"speakers": [
- "evin-mcmullen"
+ "sebastian-buergel"
]
},
"vector": [
@@ -181068,9 +180689,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -181130,6 +180748,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -181673,7 +181292,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -181720,7 +181338,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -181769,7 +181386,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -181823,6 +181439,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -181866,6 +181483,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -181909,6 +181527,7 @@
0,
0,
2,
+ 2,
0,
0,
0,
@@ -182233,10 +181852,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -182250,57 +181869,42 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "cypherpunk-is-slow-not-hyper-financialized-and-unlike-twitter",
- "sourceId": "QPQZJR",
- "title": "Cypherpunk is slow, not hyper-financialized and unlike Twitter",
- "description": "In this lightning talk I will present three major directions that we need to tackle to make Ethereum Cypherpunk:\r\n1. Against popular trends, I call for increasing block time (instead of making it faster) to increase resilience via better DVT and mixnets - both are struggling with low latency blocks\r\n2. Let's revive the Ethereum world computer, not just financial infrastructure and their implications\r\n3. Rethink [d]app UX entirely - how does resilient human interaction feel like in the digital era?",
- "track": "Cypherpunk & Privacy",
+ "id": "dacc-closing-panel",
+ "sourceId": "HTKUVS",
+ "title": "d/acc closing panel",
+ "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Community",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "latency",
- "Censorship Resistance",
- "Ethereum Roadmap",
- "Not financial"
- ],
- "keywords": [
- "Latency"
- ],
- "duration": 467,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "ngz-Zug_LS8",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": "67349e5c9dbb7a90e13140a5",
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67349e5c9dbb7a90e13140a5.vtt",
- "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you",
- "eventId": "devcon-7",
- "slot_start": 1731493200000,
- "slot_end": 1731493800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1oHb6j9HUcr5SBg9cKc9eUxdiZdwushIlE08dKhrQ1zE",
- "resources_slides": null,
"speakers": [
- "sebastian-buergel"
- ]
+ "vitalik-buterin",
+ "robin-hanson",
+ "eli-dourado"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731583200000,
+ "slot_end": 1731585000000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/15jv-W1ReL9GrekRSr8kZvYKEsNZleXRAf2BtcLW2I5s"
},
"vector": [
0,
+ 6,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -182484,6 +182088,32 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 6,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -182503,7 +182133,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -183195,7 +182824,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -183239,7 +182867,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -183283,31 +182910,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -183611,14 +183213,13 @@
2,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -183630,28 +183231,35 @@
},
{
"session": {
- "id": "dacc-closing-panel",
- "sourceId": "HTKUVS",
- "title": "d/acc closing panel",
- "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
+ "id": "dacc-social-tech-from-a-swiss-perspective",
+ "sourceId": "QXJYLY",
+ "title": "d/acc social tech from a swiss perspective",
+ "description": "Zuitzerland‘s thesis on how a permanent network state sandbox can serve as a „free social space“ and aid in scaling d/acc governance models beyond Swiss borders. Zuitzerland aims to build on the social technology developed over 700 years of decentralized governance in Switzerland, a thriving nation state, that’s no. 1 in innovation per capita, and one of the world’s only direct democracies.",
"track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
- "expertise": "",
- "audience": "Engineering",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "D/acc",
+ "Network states"
+ ],
+ "tags": [
+ "Decentralization",
+ "Economics",
+ "Governance"
+ ],
"language": "en",
"speakers": [
- "vitalik-buterin",
- "eli-dourado"
+ "isla-munro",
+ "una-wang"
],
"eventId": "devcon-7",
- "slot_start": 1731583200000,
- "slot_end": 1731585000000,
+ "slot_start": 1731580200000,
+ "slot_end": 1731580800000,
"slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/15jv-W1ReL9GrekRSr8kZvYKEsNZleXRAf2BtcLW2I5s"
+ "resources_presentation": "https://docs.google.com/presentation/d/1f6N0D4m-xFEHIkJO7OzkhfJlUtBWAno5sr5jRV3Q5kk"
},
"vector": [
0,
@@ -183844,8 +183452,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -183863,9 +183469,10 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -184439,6 +184046,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -184499,11 +184107,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -184962,13 +184572,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
2,
@@ -184979,49 +184589,54 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "dacc-social-tech-from-a-swiss-perspective",
- "sourceId": "QXJYLY",
- "title": "d/acc social tech from a swiss perspective",
- "description": "Zuitzerland‘s thesis on how a permanent network state sandbox can serve as a „free social space“ and aid in scaling d/acc governance models beyond Swiss borders. Zuitzerland aims to build on the social technology developed over 700 years of decentralized governance in Switzerland, a thriving nation state, that’s no. 1 in innovation per capita, and one of the world’s only direct democracies.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
+ "id": "daos-and-borgs-blending-the-best-trust-minimization-techniques-of-the-onchain-and-offchain-worlds",
+ "sourceId": "3E7R7G",
+ "title": "DAOs and BORGs: blending the best trust-minimization techniques of the onchain and offchain worlds",
+ "description": "In his talk, Gabriel will give an overview of the legal challenges faced by DAOs and how ‘making DAOs modular’ with specialized legal wrappers and smart contracts known as ‘cybernetic orgs” (BORGs) can solve these problems. The talk will tie the evolution of DAOs to the modular revolution in blockchain infrastructure and a detailed walk-through of how modified Gnosis SAFEs can be combined with legal entity bylaws to blend the best trust-minimization techniques of the onchain and offchain worlds.",
+ "track": "Coordination",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "D/acc",
- "Network states"
- ],
"tags": [
+ "DAO",
+ "Governance",
+ "Decentralization",
+ "cybernetics",
+ "DAO",
"Decentralization",
- "Economics",
"Governance"
],
- "language": "en",
- "speakers": [
- "isla-munro"
+ "keywords": [
+ "Cryptolaw",
+ "cybernetics"
],
+ "duration": 1641,
+ "language": "en",
+ "sources_swarmHash": "c99eeecfe8caaabcd7d43ec47b485f6adbdc298c8022c488832256b05188d012",
+ "sources_youtubeId": "2pYy07uUG4c",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673324013a168eb5355d6509.vtt",
+ "transcript_text": " . This way you do this, probably like that. Okay, cool. So this is going to be very informationally dense. The talk was labeled as intermediate, but I am going to speed run through the basics, like super speed run through them. So don't get mad that I'm going to kind of like speed run through the basics, like super speed run through them. So don't get mad that I'm going fast. Basically, yeah, it's to get to the good stuff faster, right? And then I'll slow down and take my time on the detailed interesting stuff. Yeah, as I go through, I will be saying some very opinionated and potentially controversial things as if they are fairly simple, obvious truisms. The reason why I'm doing that is just because it makes for a better talk, not because I'm like a fascist who doesn't understand all the nuances. So you can always feel free to like challenge me later on these various assertions, but it just kind of simplifies, simplifies the discussion, simplifies the presentation, et cetera. So with all that being said, I'm Gabriel Shapiro. I am what they call a crypto lawyer. I'm also more recently a founder of a company called Metalex that researches and develops certain, what we call cybernetic law solutions that include governance issues for DAOs. Covered that. So first question is, like, what is a DAO? I'm sure you guys have heard this question ad nauseum today. I will just say that, like, basically no one agrees, so the DAO that can be defined is not the true DAO, thus spake DAOzu. There are kind of like two basic answers you can give to this question, right? Oh, and let me start my timer here so I don't take too long. One is like basically if you just looked at everything that is called a DAO and tried to honor that nominal essence, so to speak, that everyone gives, it's just way too many things, right? It's like venture capital funds that use smart contracts. It's art collectives. It's protocol DAOs, things that are governing, you know, DeFi protocol parameters. Just like some people even call like Bitcoin itself a DAO as a network. Just many, many, many things. And about the best you could say is that, like, it's some type of group of people who use blockchain for at least some of their governance or, like, storing their assets or something, right? That's not a very satisfactory or precise thing. Just to give, like, an example there, yeah, like Metacartel VenturesDAO, which I actually helped found and I'll be mentioning throughout. You know, it's really a venture capital fund. It's an LLC. But it uses, like, tokenized voting, right, and uses smart contracts to hold the assets. But, you know, at the end of the day, it's just a venture capital fund, right? So that's an example of, like, how diverse these things called DAOs can be, right? My answer is, like, I have a much more opinionated answer, which is I go for like a purist definition of DAOs, right? And I just look at the word, right? The acronym DAO, right? So at a minimum, DAOs must be decentralized and autonomous and some kind of organization, right? What does decentralized mean? It means that whatever like the human discretion is in running this thing, like it's dispersed over a large agile and potentially anonymous group of incentive aligned persons. And we prefer that it's like a permissionless or relatively lightly permissioned like entry into that group so that it can be very broad and so that there are no like unfair hoardings of power, so to speak. And autonomous to me means that it's self-governing, self-governing, trust-minimized, and resistant to extrinsic exercises of power. So the intrinsic power is decentralized, and the extrinsic power is hopefully close to eliminated. And you can actually go back to the original thing that inspired DAOs, which is an article by Stan Larimer, not Dan Larimer, although I think they might be cousins, arguing that Bitcoin is a decentralized autonomous corporation. And he had three rules for what he called DAX, what we now call DAOs. They basically have three laws of robotics, or what we call three laws of DAObotics. Law number one is that a DAO must run under the control of an incorruptible set of rules that are implemented as publicly auditable open source software. Law number two, a DAO must not be able to change its rules without the consent of its stakeholders, and such consent must not violate law number one. And law number three, a DAO must seek to protect its own existence as long as that does not violate law number one or law number two. Now what is a Borg? You may have heard this term, maybe not all of you have heard of it, but it is a cybernetic organization, hence Borg. And what that means is it's some kind of like real legal entity, could be incorporated or unincorporated, could be a partnership, but most likely is going to be incorporated, where the rules of that entity, the legal rules of that entity mandate the use of certain smart contract or blockchain systems, right? So this represents a blend of legal and on-chain technology, right? There are two main varieties. One is DAO adjacent, right? So if you've ever heard of any type of multi-sig that can freeze a DeFi protocol or some type of grants multisig that is funded by a DAO. That's basically a DAO-adjacent Borg. An example would be like Curves Emergency Multisig. It can freeze pools that are 30 days or younger, and it can stop Curve rewards to a pool, and it can't really do anything else. And the other would be like BizBorg. So this would be something like Meta Cartel Ventures DAO, which I mentioned earlier, or like a corporation that like tokenizes all of its shares and lets them vote on chain and distributes funds on chain. Why is a Borg not a DAO? Well, it lacks autonomy and it lacks decentralization. Basically, it violates those rules I mentioned earlier, right? I won't dwell on that, but it's there in the slides if you want to see exactly why. Also, side note, why Borgs and not sub DAOs? You may have heard of the sub DAO model. Well, sub DAOs are usually not DAOs. They are usually small groups of multi-sig holders, again, that for some reason people call sub DAOs. So, again, they violate those rules. They're not decentralized. They're not autonomous. From a legal perspective, you really don't want, if these things are like some small group of people who may incur liabilities or do bad things, you don't really want them to be sub DAOs because then the DAO may have legal liability for them. You want them to be more separate and autonomous. Securities law is also, you know, if like the DAO token holders are basically like electing, like just fully electing these people and it's more of an agency type relationship, you might be turning your DAO tokens into shares and securities. So these things, these like, we have various trust problems with DAOs and with multisigs. And the ethos of crypto is verified, don't trust, right? So the point of this talk, the point of this entire track is coordination, right? How to solve these problems. And Borgs are basically a technique for doing this. The first trust problem that is faced by these like multisigs in relation to DAOs is member management, right? Oftentimes when a multi-sig is, a DAO adjacent multi-sig is proposed, it's with like a very specific membership set. It might be people who are doxed, it might be people who are pseudonyms like the well-known Bantag who's like very high reputation as a NIM, right? But nonetheless it is a specific set. But how do you accommodate over time membership changes? Who decides that? And the default is that these things are just a standard safe, and therefore those people decide the membership changes. But the DAO seems to care who the members are, yet the people who were appointed, they can change their membership willy-nilly, and they never have to go back to the DAO. That's a problem, right? Particularly a problem if there is no other recourse against these people, as is typically the case, other than, quote-unquote, reputation slashing, right? If they do something bad, they will lose their reputation, and they will never be appointed to one of these things again. Okay, but that's great for the initial set of potentially high-reputation people who are appointed, but what if it changes over time to like lower reputation people? Or what if the people who like claim to be on it, like immediately actually just like assign the keys to someone else or something and you could never know, right? The other trust problem is asset management, right? Often these things, I mean, I think like Arbitrum recently approved like a hundred, over a hundred million to some like gaming grant support type of thing, right? And they're putting in place trust mitigation measures, but this thing happens all the time, right? These multi-sigs get, these DAO adjacent entities get large amounts of money from a DAO, right? And this presents various issues. Number one, like transparency of asset management, right? And like one thing to notice is that if you just like, you may think that the fact that these funds initially go to a multi-sig means, oh, it will be transparent. But actually, in the default case, the multi-sig can just immediately send them to a centralized exchange or to a custodian or sell them for fiat and put it into a bank account and all that transparency would be lost. And there's typically nothing that can be done about that. There's no legal rule against it. There's also no on-chain mechanism that typically prevents it. So the transparency isn't really there, actually. And asset management accountability, they're supposed to do specific things with these assets, but there's often no way to enforce that either, again, other than this sort of idea of reputation slashing. The other issue is permissions management, right? So I mentioned Curve Emergency DAO, or Curve Emergency Board earlier, that has certain specific permissions over the Curve smart contract system, but it's only supposed to use them for specific reasons, right? Like basically if there's some sort of security emergency. So it would be like very bad if someone is on that multisig and let's just say, well, let's just say it's someone from Curve and let's just say like Uniswap community tried to do like a Uni stablecoin pool on Curve and just because there are competing protocols, the Curve people didn't like it and they shut off Curve rewards to that pool or they killed that pool, right? That would be bad because it's not for a security reason, right? But actually there's, like, no way to really, like, enforce that or even make clear that that is an actual rule. An example here from real life is that Kujira, basically the devs had a highly levered position themselves in their own borrowing protocol, and they used their multisig authorities to change the parameters in their favor and just kick the can down the road over and over again, and eventually resulted in a protocol insolvency that could have lost people a lot of money if they were not bailed out by 14 people. The other thing is that, like, you can actually have bad mitigations to all the problems I mentioned, right? One is that you, like, basically you just put the DAO in complete control of everything. And, again, that lapses into the sub-DAO model. And it also may really result in, like, an adverse selection effect in terms of who can contribute to the community so to speak right because if like you can get rugged at any time by a DAO well really valuable serious people are not going to operate under that they want either employment law protections or they want some kind of deal where like if I produce x you will pay me y and if you don't pay me y I can come and sue you right and that is not really possible with that type of just make the DAO supreme type of mitigation. So it will lead to adverse selection. And, in fact, I know of quality teams that just have a rule of, you know, we will not work with DAOs. We will not do projects for DAOs. A concrete example here is JunoDAO had set up a very complicated and I thought somewhat promising looking sub-DAO structure earlier this year. And I think it took like months. I don't know all the details. And the DAO just kind of changed its mind and rugged all those people before it even really got rolling. Now, maybe they were doing some stuff wrong. I don't know. But, you know, it shows how things could be bad, right? And how people could be reluctant to do these. There also are trust issues faced by, like, extrinsic counterparties, right? Like, many law firms will not represent DAOs, cannot represent DAOs, right, because they're not legal entities. Basically, some of the things that I mentioned, like, during the last slide, like, third parties can get screwed and will often not want to do deals with DAOs. So to address these with Borgs, there are basically two sets of techniques. One is on-chain techniques and one is off-chain techniques. And we try to blend the best of both, right? I often say, like, a lot of on-chain stuff currently that's, like, decentralized in name only is actually the worst of both worlds, right? It has none of the protections of law and it actually has, like, none of the protections of true decentralization either. And so we actually tried to do the opposite. We tried to do the best of both worlds with Borgs. Some of the on-chain techniques is, like, okay, so almost all multi-sigs are what's called a safe. It's a very standard, very battle-tested, very trusted set of smart contracts, originally by the Gnosis team, now it's an independent team, and the genius thing that they did is they built hooks into these. Hooks for guards and hooks for modules. So without ever altering the core code, you can come in and you can modify the way that a safe functions. And we actually use this, right? We use this to limit the discretion of the safe, and also to enable third parties to do things to the safe. And this results in a can't be evil philosophy instead of a don't be evil philosophy. So guards basically constrain safes, right? Like they basically can check, you know, they could literally limit it to only sending money to a certain account or something like that. And then modules expand safes. Like, they could allow a DAO to come in and send money out of the safe somewhere without the multisig signer signing that transaction, right? So we call both these things implants, keeping with the cybernetic law type of theme, right? It's like cyborgs. So like basically we can, like at a very high level, the guards can make the Borg a whitelist style, a blacklist style, or a freestyle, right? Whitelist means everything is prohibited by default except what we specifically allow, right? So this could be like, let's just say it's a Borg that is only supposed to move liquidity among specific Uniswap pools, you could just whitelist those pools and nothing, and they can't do anything else. They could just shuffle liquidity between these certain pools, right? So it tends to be good for Borgs that have a lot of money in them. You could also do, we'll talk about grants Borgs, but you can like rate limit the speed at which money comes out or like add transaction size thresholds or things like this. Blacklist is like everything is permitted except certain things. So an example of this would be like a Borg. Let's just say it's a token that retains a mintable function, so it doesn't have a cap supply. And there's a trust issue there, right, because people don't want to get infinitely diluted for no reason. So you could blacklist this Borg, you could give it the permission to do, to sort of, basically it could like partially own the mint function, right? So in order to exercise the mint function you would need the approval both of this safe or this Borg and the DAO, for example, right? And that would be an example of a blacklist. And then free is like basically the safe can do anything, but maybe you want some of the other functions that we're going to talk about, like member management functions. So how do we address like the asset management trust issues I mentioned, right? So basically, let's just take like a grants bargain as an example. We can add like rate limitations, right? So let's just say the idea that the DAO approved is like this should be a fire starter board. Like it should give out lots and lots of 50K to 100K grants and no bigger, right? And it should do this like several times a quarter for three years or something like that. Well, we can actually program that in to the safe, right? And then they have to do that. They can't do anything different, right? And you still want to retain flexibility. So the nice thing is you can either allow, like, the caps and the rate limits to be crossed if the DAO co-approves that along with the safe, or you can put, like like a potential violation of a cap or a rate limit subject to a time lock and allow a DAO veto within that time period, right? Depends whether you want to be optimistic or pessimistic, right? So, you know, we can implement that veto functionality and that co-approval functionality. You can also throw in like anti-DOS measures, right? If you're worried about that. You're worried about the board will just spam the DAO and overwhelm its monitoring capabilities. You can impose cool downs between proposals. Member management issues. So this is the beauty of having a legal entity, which we'll talk about in a minute. But you can have one legal entity that owns this multisig forever and its assets, and it doesn't matter how much turnover there is in the members, right? It still has the same rules and the same set of smart contracts and all these things, right? So, but what we want to do is we may just not want to allow infinite discretion to the safe members to change their own membership. So you could, for example, require like a DAO co-approval or subject it to a DAO veto when a new member is added. You could potentially say, hey, these guys might all collude and there's no way to get them off. So maybe you allow the DAO to like unilaterally remove members, even though it can't unilaterally appoint members. There's all kinds of things you can do, right? But the point is to de-risk and trust minimize this member management function. This could be very important for an entity that owns IP, for example. If, like, let's just say the entity's rules say this particular safe, everyone who's on it is a director of this entity, and then the entity owns the IP. Well, now the DAO basically has, like, permanent check and balance style influence over the IP, and there's, like, no risk of disruption, right? Things like that. You can also put in like fail-safe measures so that if like too many, like you can allow people to resign. That helps basically with like trust minimize it for the contributors, right? Because like typically someone can resign from a company, but you can't actually do that in a default safe. You have to be voted off. You can also do like in a default safe. You have to be voted off. You can also do asset reversion measures, like if too many people resign or whatever, all the money goes back to the DAO, whatever you want to do. And then there are off-chain techniques for managing these issues, right? So the first thing is have a legal wrapper for your DAO-adjacent BORG. We could sit here and debate a legal wrapper for your DAO itself. I think this is very, very debatable, and there are significant cons to it. But there are almost no cons to wrapping your multisig, your DAO adjacent multisig in a legal entity. As far as I can tell, it's like pure upside, other than maybe some added expense, right? So, you know, it gets limited liability for the workers. It gets continuity for the DAO that we discussed. And then like entities are much, much like legal entities and corporate entities are much, much better counterparties for third parties than like a general partnership with unclear rules is, right? So there's all kinds of benefits. Basically, you say in the legal docs of the entity that the entity owns this particular safe and all the assets in the safe. And you also can say something like everyone who's who's in this safe is a signer in the safe is automatically a director of this entity, and vice versa. Anyone who's a director needs to be on the safe. Things like that, right? You need to choose the type of legal wrapper wisely. I'll kind of skip through this quickly because we're running out of time, but corporations are not very good legal wrappers for DAO-adjacent multisigs. They have very rigid rules. LLCs are more flexible, but they still have the problem that, like, they're geared for, like, to be owned by people, right? And we actually don't want these entities to be owned. We want them to basically be as close as possible to, like, the idea of a legal smart contract, right? There's a set of rules and there's people who have to follow them, but there's no owner, there's no specific beneficiary, et cetera. The best for that, as far as I've ever been able to tell with all my research, is Cayman Foundation. It's the only one that kind of checks all the boxes. Some other foundations can work, but they have like more rigid like founder structures or beneficiary structures or reporting things. It just came in as the best, right? And so here's how we actually do this in, like, the legal documents, right? So one, you really want to define, like, the purposes of what this entity is supposed to do, right? If it's a security multisig, its purpose is to defend against security threats, right? You want to say that in the documents. Therefore, it cannot use the assets for anything else. It cannot use the permissions for anything else, right? So we literally spell that out. We define security threats. In this case, it means any actual or reasonably expected threat into imminent pending or ongoing frauds, threats, misappropriations, extortions, abuses, hacks, attacks, et cetera, et cetera, against these specific systems. And those systems will also be defined with like specific contract addresses and things like that um like of course you could always debate these things and then of course like you may end up in court but it's still better than having like no standard or no rule at all um you can also we already discussed like making your safe members the same as your board of directors um you can basically you can be much more parsimonious in your legal drafting than you could ordinarily, because instead of like spelling out pages and pages of rules, you could just say, whatever the rules are embedded in that smart contract, we have agreed to them. We've diligenced these smart contracts, and they embed our rules, and we just accept their outcomes, right? Another one is, this is very handy with the foundations, you can have an emergency supervisor role. So you can basically say, hey, if the DAO, the whole point here is that this board was set, authorized by the DAO, given some resources with a very specific set of rules. Who is going to enforce those rules? Because remember, there are no owners, there are no beneficiaries, there are only rules and people who follow them. So what happens if they don't follow them, right? We try to make sure that they have to follow them with the on-chain stuff as much as possible, but it's not going to cover everything, right? For example, it's not going to cover, it's not going to prevent them from transferring IP, right? So we need legal rules for that. rules, it can appoint an emergency supervisor and this person is authorized under both statute and contract to come in, sue in the name of the DAO, investigate, hold people responsible, remove people who broke the rules, that sort of thing. It's kind of like a nuclear option on the off-chain legal side. Amendments, right? This would be a way that everything could be rubbed, right? If the board of directors has the authority to amend the bylaws and the bylaws are the things that say, hey, use the IP to the benefit of LidoDAO or whatever, well, that's a potential big end run, right? They could just amend it and expand it or whatever. So you need a rule that says any amendment also requires like a DAO vote. Or it could be the vote of some other multi-sig or some other foundation entity or whatever, right? But the point is you trust minimize it. And kind of like the last technique is like people, if these boards are going to be entering into legal agreements with people, the broader community probably wants transparency on that. So one thing we're doing is what we call Ricardian triplers. This has a technical definition, which I don't have time to give you right now, but the basic idea is, like, you can have a standard agreement, and if someone is signing up to the multisig, well, they would just sign this on-chain, and the variables are literally instantiated on-chain, right? So anyone could look at the chain and reconstruct. They could look at the chain plus the IPFS hash of this agreement, which would have been in the function call, and they can know exactly what agreements this has and who agreed to them and who signed it. So that's really it. One kind of like big meme I will just give you guys that I wasn't able to fit into this very short presentation is like think about the modular trend in blockchains generally, right? You have these big, highly decentralized, highly autonomous L1s. And then you have L2s that are more centralized, but also sort of like more expendable, right? And they have feedback loops with the L1. What have we just described with Borgs and DAOs? Same thing, right? It's the same exact trend. We now have modular designs. You can have a DAO that's surrounded by a bunch of Borgs, just like you could have Ethereum that's surrounded by a bunch of L2s, right? So there's this nice parallelism there. And that's really it. Awesome, Gabriel. Thank you so much. We have time for one question. So who wants to go and be the lucky person? One question for Gabriel. Here, please. The microphone. It's coming to you. It's coming to you. Gabriel, thank you very much for the presentation. I would love to have it because there is lots of valuable stuff. My question is that do you think if there will be a market for the Borgs, for instance, like if the different organizations could like shop for different Borgs that provide certain functions to it? Yeah, absolutely. I think there could be like even a market for like the implants, right? Like you can just add and remove implants as you need them as your organization evolves. And we talked about the DAO adjacent ones here, but actually I think the same approach makes sense for any type of entity, right? Your ordinary corporation, well, the board of directors could be a safe, the stockholders can be like a tokenized dow with like tokenized shares that vote and everything could be much more transparent and in my opinion efficient right because right now if you do um like a like a board of directors resolution let's it's called an action by written consent in delaware well that's saying something should be done or it's authorizing something to happen, but it doesn't in one and the same moment actually cause the transaction to happen. But if your written consents are safe signatures, and it's authorizing sending the money somewhere, in one and the same action of approving it, you're also doing it, right? So it's just obvious to me that it's much more efficient and much more powerful, much more composable, all those things. And I think we will have, yeah, marketplaces that have these implants, marketplaces that have Borgs. And if they're all on the same standard, it actually makes them much easier to do deals with each other. Like imagine a merger of two Borg-ed up corporations where the tokenized shares are on the same standard so that literally you could just call a function and one one set of shares merges into the other right on chain so that's the kind of stuff we're trying to build at my company metal x thank you so much please giving a great applause i appreciate that gabriel",
"eventId": "devcon-7",
- "slot_start": 1731580200000,
- "slot_end": 1731580800000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1f6N0D4m-xFEHIkJO7OzkhfJlUtBWAno5sr5jRV3Q5kk"
+ "slot_start": 1731402000000,
+ "slot_end": 1731403800000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Pq-UfROf_3nVsy2VhJLpxOcTmyPsVPQsHMIH4SZRIfY",
+ "resources_slides": null,
+ "speakers": [
+ "gabriel-shapiro"
+ ]
},
"vector": [
- 0,
- 6,
- 0,
0,
0,
0,
@@ -185033,6 +184648,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -185229,10 +184845,10 @@
0,
0,
0,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -185806,7 +185422,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -185872,7 +185487,7 @@
0,
0,
0,
- 0,
+ 2,
2,
0,
0,
@@ -186008,7 +185623,7 @@
0,
0,
0,
- 0,
+ 2,
0,
0,
0,
@@ -186337,11 +185952,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -186354,46 +185969,46 @@
},
{
"session": {
- "id": "daos-and-borgs-blending-the-best-trust-minimization-techniques-of-the-onchain-and-offchain-worlds",
- "sourceId": "3E7R7G",
- "title": "DAOs and BORGs: blending the best trust-minimization techniques of the onchain and offchain worlds",
- "description": "In his talk, Gabriel will give an overview of the legal challenges faced by DAOs and how ‘making DAOs modular’ with specialized legal wrappers and smart contracts known as ‘cybernetic orgs” (BORGs) can solve these problems. The talk will tie the evolution of DAOs to the modular revolution in blockchain infrastructure and a detailed walk-through of how modified Gnosis SAFEs can be combined with legal entity bylaws to blend the best trust-minimization techniques of the onchain and offchain worlds.",
+ "id": "daos-unmasked-the-hard-truths-behind-the-hype",
+ "sourceId": "ZSSKBL",
+ "title": "DAOs Unmasked: The Hard Truths Behind the Hype",
+ "description": "In this talk we will see what a DAO is, what its not and face some hard truths about DAOs and how they are used today.\r\n\r\nDoes a DAO stand for Discord Administered Organization? Is a DAO just a discord chat and a multisig?\r\n\r\nIs a DAO a way for your company to have 2 cap tables, one for your and your investors and one for your community?\r\n\r\nAre DAOs a face for a Cayman Islands foundation which uses decentralization theater to shift liability?\r\n\r\nAre DAOs a way to sidestep regulations?\r\n\r\nLet's find out!",
"track": "Coordination",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"tags": [
+ "Coordination",
"DAO",
"Governance",
- "Decentralization",
- "cybernetics",
+ "Regulation",
+ "Coordination",
"DAO",
- "Decentralization",
"Governance"
],
"keywords": [
- "Cryptolaw",
- "cybernetics"
+ "Decentralization Theater",
+ "Regulation"
],
- "duration": 1641,
+ "duration": 1670,
"language": "en",
- "sources_swarmHash": "c99eeecfe8caaabcd7d43ec47b485f6adbdc298c8022c488832256b05188d012",
- "sources_youtubeId": "2pYy07uUG4c",
+ "sources_swarmHash": "ecced45caf16ee62282cfbd6014f1bbf67c2b02c548c9d1fee650b8fc8ba5a2c",
+ "sources_youtubeId": "pdlMrmUxpSg",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673324013a168eb5355d6509.vtt",
- "transcript_text": " . This way you do this, probably like that. Okay, cool. So this is going to be very informationally dense. The talk was labeled as intermediate, but I am going to speed run through the basics, like super speed run through them. So don't get mad that I'm going to kind of like speed run through the basics, like super speed run through them. So don't get mad that I'm going fast. Basically, yeah, it's to get to the good stuff faster, right? And then I'll slow down and take my time on the detailed interesting stuff. Yeah, as I go through, I will be saying some very opinionated and potentially controversial things as if they are fairly simple, obvious truisms. The reason why I'm doing that is just because it makes for a better talk, not because I'm like a fascist who doesn't understand all the nuances. So you can always feel free to like challenge me later on these various assertions, but it just kind of simplifies, simplifies the discussion, simplifies the presentation, et cetera. So with all that being said, I'm Gabriel Shapiro. I am what they call a crypto lawyer. I'm also more recently a founder of a company called Metalex that researches and develops certain, what we call cybernetic law solutions that include governance issues for DAOs. Covered that. So first question is, like, what is a DAO? I'm sure you guys have heard this question ad nauseum today. I will just say that, like, basically no one agrees, so the DAO that can be defined is not the true DAO, thus spake DAOzu. There are kind of like two basic answers you can give to this question, right? Oh, and let me start my timer here so I don't take too long. One is like basically if you just looked at everything that is called a DAO and tried to honor that nominal essence, so to speak, that everyone gives, it's just way too many things, right? It's like venture capital funds that use smart contracts. It's art collectives. It's protocol DAOs, things that are governing, you know, DeFi protocol parameters. Just like some people even call like Bitcoin itself a DAO as a network. Just many, many, many things. And about the best you could say is that, like, it's some type of group of people who use blockchain for at least some of their governance or, like, storing their assets or something, right? That's not a very satisfactory or precise thing. Just to give, like, an example there, yeah, like Metacartel VenturesDAO, which I actually helped found and I'll be mentioning throughout. You know, it's really a venture capital fund. It's an LLC. But it uses, like, tokenized voting, right, and uses smart contracts to hold the assets. But, you know, at the end of the day, it's just a venture capital fund, right? So that's an example of, like, how diverse these things called DAOs can be, right? My answer is, like, I have a much more opinionated answer, which is I go for like a purist definition of DAOs, right? And I just look at the word, right? The acronym DAO, right? So at a minimum, DAOs must be decentralized and autonomous and some kind of organization, right? What does decentralized mean? It means that whatever like the human discretion is in running this thing, like it's dispersed over a large agile and potentially anonymous group of incentive aligned persons. And we prefer that it's like a permissionless or relatively lightly permissioned like entry into that group so that it can be very broad and so that there are no like unfair hoardings of power, so to speak. And autonomous to me means that it's self-governing, self-governing, trust-minimized, and resistant to extrinsic exercises of power. So the intrinsic power is decentralized, and the extrinsic power is hopefully close to eliminated. And you can actually go back to the original thing that inspired DAOs, which is an article by Stan Larimer, not Dan Larimer, although I think they might be cousins, arguing that Bitcoin is a decentralized autonomous corporation. And he had three rules for what he called DAX, what we now call DAOs. They basically have three laws of robotics, or what we call three laws of DAObotics. Law number one is that a DAO must run under the control of an incorruptible set of rules that are implemented as publicly auditable open source software. Law number two, a DAO must not be able to change its rules without the consent of its stakeholders, and such consent must not violate law number one. And law number three, a DAO must seek to protect its own existence as long as that does not violate law number one or law number two. Now what is a Borg? You may have heard this term, maybe not all of you have heard of it, but it is a cybernetic organization, hence Borg. And what that means is it's some kind of like real legal entity, could be incorporated or unincorporated, could be a partnership, but most likely is going to be incorporated, where the rules of that entity, the legal rules of that entity mandate the use of certain smart contract or blockchain systems, right? So this represents a blend of legal and on-chain technology, right? There are two main varieties. One is DAO adjacent, right? So if you've ever heard of any type of multi-sig that can freeze a DeFi protocol or some type of grants multisig that is funded by a DAO. That's basically a DAO-adjacent Borg. An example would be like Curves Emergency Multisig. It can freeze pools that are 30 days or younger, and it can stop Curve rewards to a pool, and it can't really do anything else. And the other would be like BizBorg. So this would be something like Meta Cartel Ventures DAO, which I mentioned earlier, or like a corporation that like tokenizes all of its shares and lets them vote on chain and distributes funds on chain. Why is a Borg not a DAO? Well, it lacks autonomy and it lacks decentralization. Basically, it violates those rules I mentioned earlier, right? I won't dwell on that, but it's there in the slides if you want to see exactly why. Also, side note, why Borgs and not sub DAOs? You may have heard of the sub DAO model. Well, sub DAOs are usually not DAOs. They are usually small groups of multi-sig holders, again, that for some reason people call sub DAOs. So, again, they violate those rules. They're not decentralized. They're not autonomous. From a legal perspective, you really don't want, if these things are like some small group of people who may incur liabilities or do bad things, you don't really want them to be sub DAOs because then the DAO may have legal liability for them. You want them to be more separate and autonomous. Securities law is also, you know, if like the DAO token holders are basically like electing, like just fully electing these people and it's more of an agency type relationship, you might be turning your DAO tokens into shares and securities. So these things, these like, we have various trust problems with DAOs and with multisigs. And the ethos of crypto is verified, don't trust, right? So the point of this talk, the point of this entire track is coordination, right? How to solve these problems. And Borgs are basically a technique for doing this. The first trust problem that is faced by these like multisigs in relation to DAOs is member management, right? Oftentimes when a multi-sig is, a DAO adjacent multi-sig is proposed, it's with like a very specific membership set. It might be people who are doxed, it might be people who are pseudonyms like the well-known Bantag who's like very high reputation as a NIM, right? But nonetheless it is a specific set. But how do you accommodate over time membership changes? Who decides that? And the default is that these things are just a standard safe, and therefore those people decide the membership changes. But the DAO seems to care who the members are, yet the people who were appointed, they can change their membership willy-nilly, and they never have to go back to the DAO. That's a problem, right? Particularly a problem if there is no other recourse against these people, as is typically the case, other than, quote-unquote, reputation slashing, right? If they do something bad, they will lose their reputation, and they will never be appointed to one of these things again. Okay, but that's great for the initial set of potentially high-reputation people who are appointed, but what if it changes over time to like lower reputation people? Or what if the people who like claim to be on it, like immediately actually just like assign the keys to someone else or something and you could never know, right? The other trust problem is asset management, right? Often these things, I mean, I think like Arbitrum recently approved like a hundred, over a hundred million to some like gaming grant support type of thing, right? And they're putting in place trust mitigation measures, but this thing happens all the time, right? These multi-sigs get, these DAO adjacent entities get large amounts of money from a DAO, right? And this presents various issues. Number one, like transparency of asset management, right? And like one thing to notice is that if you just like, you may think that the fact that these funds initially go to a multi-sig means, oh, it will be transparent. But actually, in the default case, the multi-sig can just immediately send them to a centralized exchange or to a custodian or sell them for fiat and put it into a bank account and all that transparency would be lost. And there's typically nothing that can be done about that. There's no legal rule against it. There's also no on-chain mechanism that typically prevents it. So the transparency isn't really there, actually. And asset management accountability, they're supposed to do specific things with these assets, but there's often no way to enforce that either, again, other than this sort of idea of reputation slashing. The other issue is permissions management, right? So I mentioned Curve Emergency DAO, or Curve Emergency Board earlier, that has certain specific permissions over the Curve smart contract system, but it's only supposed to use them for specific reasons, right? Like basically if there's some sort of security emergency. So it would be like very bad if someone is on that multisig and let's just say, well, let's just say it's someone from Curve and let's just say like Uniswap community tried to do like a Uni stablecoin pool on Curve and just because there are competing protocols, the Curve people didn't like it and they shut off Curve rewards to that pool or they killed that pool, right? That would be bad because it's not for a security reason, right? But actually there's, like, no way to really, like, enforce that or even make clear that that is an actual rule. An example here from real life is that Kujira, basically the devs had a highly levered position themselves in their own borrowing protocol, and they used their multisig authorities to change the parameters in their favor and just kick the can down the road over and over again, and eventually resulted in a protocol insolvency that could have lost people a lot of money if they were not bailed out by 14 people. The other thing is that, like, you can actually have bad mitigations to all the problems I mentioned, right? One is that you, like, basically you just put the DAO in complete control of everything. And, again, that lapses into the sub-DAO model. And it also may really result in, like, an adverse selection effect in terms of who can contribute to the community so to speak right because if like you can get rugged at any time by a DAO well really valuable serious people are not going to operate under that they want either employment law protections or they want some kind of deal where like if I produce x you will pay me y and if you don't pay me y I can come and sue you right and that is not really possible with that type of just make the DAO supreme type of mitigation. So it will lead to adverse selection. And, in fact, I know of quality teams that just have a rule of, you know, we will not work with DAOs. We will not do projects for DAOs. A concrete example here is JunoDAO had set up a very complicated and I thought somewhat promising looking sub-DAO structure earlier this year. And I think it took like months. I don't know all the details. And the DAO just kind of changed its mind and rugged all those people before it even really got rolling. Now, maybe they were doing some stuff wrong. I don't know. But, you know, it shows how things could be bad, right? And how people could be reluctant to do these. There also are trust issues faced by, like, extrinsic counterparties, right? Like, many law firms will not represent DAOs, cannot represent DAOs, right, because they're not legal entities. Basically, some of the things that I mentioned, like, during the last slide, like, third parties can get screwed and will often not want to do deals with DAOs. So to address these with Borgs, there are basically two sets of techniques. One is on-chain techniques and one is off-chain techniques. And we try to blend the best of both, right? I often say, like, a lot of on-chain stuff currently that's, like, decentralized in name only is actually the worst of both worlds, right? It has none of the protections of law and it actually has, like, none of the protections of true decentralization either. And so we actually tried to do the opposite. We tried to do the best of both worlds with Borgs. Some of the on-chain techniques is, like, okay, so almost all multi-sigs are what's called a safe. It's a very standard, very battle-tested, very trusted set of smart contracts, originally by the Gnosis team, now it's an independent team, and the genius thing that they did is they built hooks into these. Hooks for guards and hooks for modules. So without ever altering the core code, you can come in and you can modify the way that a safe functions. And we actually use this, right? We use this to limit the discretion of the safe, and also to enable third parties to do things to the safe. And this results in a can't be evil philosophy instead of a don't be evil philosophy. So guards basically constrain safes, right? Like they basically can check, you know, they could literally limit it to only sending money to a certain account or something like that. And then modules expand safes. Like, they could allow a DAO to come in and send money out of the safe somewhere without the multisig signer signing that transaction, right? So we call both these things implants, keeping with the cybernetic law type of theme, right? It's like cyborgs. So like basically we can, like at a very high level, the guards can make the Borg a whitelist style, a blacklist style, or a freestyle, right? Whitelist means everything is prohibited by default except what we specifically allow, right? So this could be like, let's just say it's a Borg that is only supposed to move liquidity among specific Uniswap pools, you could just whitelist those pools and nothing, and they can't do anything else. They could just shuffle liquidity between these certain pools, right? So it tends to be good for Borgs that have a lot of money in them. You could also do, we'll talk about grants Borgs, but you can like rate limit the speed at which money comes out or like add transaction size thresholds or things like this. Blacklist is like everything is permitted except certain things. So an example of this would be like a Borg. Let's just say it's a token that retains a mintable function, so it doesn't have a cap supply. And there's a trust issue there, right, because people don't want to get infinitely diluted for no reason. So you could blacklist this Borg, you could give it the permission to do, to sort of, basically it could like partially own the mint function, right? So in order to exercise the mint function you would need the approval both of this safe or this Borg and the DAO, for example, right? And that would be an example of a blacklist. And then free is like basically the safe can do anything, but maybe you want some of the other functions that we're going to talk about, like member management functions. So how do we address like the asset management trust issues I mentioned, right? So basically, let's just take like a grants bargain as an example. We can add like rate limitations, right? So let's just say the idea that the DAO approved is like this should be a fire starter board. Like it should give out lots and lots of 50K to 100K grants and no bigger, right? And it should do this like several times a quarter for three years or something like that. Well, we can actually program that in to the safe, right? And then they have to do that. They can't do anything different, right? And you still want to retain flexibility. So the nice thing is you can either allow, like, the caps and the rate limits to be crossed if the DAO co-approves that along with the safe, or you can put, like like a potential violation of a cap or a rate limit subject to a time lock and allow a DAO veto within that time period, right? Depends whether you want to be optimistic or pessimistic, right? So, you know, we can implement that veto functionality and that co-approval functionality. You can also throw in like anti-DOS measures, right? If you're worried about that. You're worried about the board will just spam the DAO and overwhelm its monitoring capabilities. You can impose cool downs between proposals. Member management issues. So this is the beauty of having a legal entity, which we'll talk about in a minute. But you can have one legal entity that owns this multisig forever and its assets, and it doesn't matter how much turnover there is in the members, right? It still has the same rules and the same set of smart contracts and all these things, right? So, but what we want to do is we may just not want to allow infinite discretion to the safe members to change their own membership. So you could, for example, require like a DAO co-approval or subject it to a DAO veto when a new member is added. You could potentially say, hey, these guys might all collude and there's no way to get them off. So maybe you allow the DAO to like unilaterally remove members, even though it can't unilaterally appoint members. There's all kinds of things you can do, right? But the point is to de-risk and trust minimize this member management function. This could be very important for an entity that owns IP, for example. If, like, let's just say the entity's rules say this particular safe, everyone who's on it is a director of this entity, and then the entity owns the IP. Well, now the DAO basically has, like, permanent check and balance style influence over the IP, and there's, like, no risk of disruption, right? Things like that. You can also put in like fail-safe measures so that if like too many, like you can allow people to resign. That helps basically with like trust minimize it for the contributors, right? Because like typically someone can resign from a company, but you can't actually do that in a default safe. You have to be voted off. You can also do like in a default safe. You have to be voted off. You can also do asset reversion measures, like if too many people resign or whatever, all the money goes back to the DAO, whatever you want to do. And then there are off-chain techniques for managing these issues, right? So the first thing is have a legal wrapper for your DAO-adjacent BORG. We could sit here and debate a legal wrapper for your DAO itself. I think this is very, very debatable, and there are significant cons to it. But there are almost no cons to wrapping your multisig, your DAO adjacent multisig in a legal entity. As far as I can tell, it's like pure upside, other than maybe some added expense, right? So, you know, it gets limited liability for the workers. It gets continuity for the DAO that we discussed. And then like entities are much, much like legal entities and corporate entities are much, much better counterparties for third parties than like a general partnership with unclear rules is, right? So there's all kinds of benefits. Basically, you say in the legal docs of the entity that the entity owns this particular safe and all the assets in the safe. And you also can say something like everyone who's who's in this safe is a signer in the safe is automatically a director of this entity, and vice versa. Anyone who's a director needs to be on the safe. Things like that, right? You need to choose the type of legal wrapper wisely. I'll kind of skip through this quickly because we're running out of time, but corporations are not very good legal wrappers for DAO-adjacent multisigs. They have very rigid rules. LLCs are more flexible, but they still have the problem that, like, they're geared for, like, to be owned by people, right? And we actually don't want these entities to be owned. We want them to basically be as close as possible to, like, the idea of a legal smart contract, right? There's a set of rules and there's people who have to follow them, but there's no owner, there's no specific beneficiary, et cetera. The best for that, as far as I've ever been able to tell with all my research, is Cayman Foundation. It's the only one that kind of checks all the boxes. Some other foundations can work, but they have like more rigid like founder structures or beneficiary structures or reporting things. It just came in as the best, right? And so here's how we actually do this in, like, the legal documents, right? So one, you really want to define, like, the purposes of what this entity is supposed to do, right? If it's a security multisig, its purpose is to defend against security threats, right? You want to say that in the documents. Therefore, it cannot use the assets for anything else. It cannot use the permissions for anything else, right? So we literally spell that out. We define security threats. In this case, it means any actual or reasonably expected threat into imminent pending or ongoing frauds, threats, misappropriations, extortions, abuses, hacks, attacks, et cetera, et cetera, against these specific systems. And those systems will also be defined with like specific contract addresses and things like that um like of course you could always debate these things and then of course like you may end up in court but it's still better than having like no standard or no rule at all um you can also we already discussed like making your safe members the same as your board of directors um you can basically you can be much more parsimonious in your legal drafting than you could ordinarily, because instead of like spelling out pages and pages of rules, you could just say, whatever the rules are embedded in that smart contract, we have agreed to them. We've diligenced these smart contracts, and they embed our rules, and we just accept their outcomes, right? Another one is, this is very handy with the foundations, you can have an emergency supervisor role. So you can basically say, hey, if the DAO, the whole point here is that this board was set, authorized by the DAO, given some resources with a very specific set of rules. Who is going to enforce those rules? Because remember, there are no owners, there are no beneficiaries, there are only rules and people who follow them. So what happens if they don't follow them, right? We try to make sure that they have to follow them with the on-chain stuff as much as possible, but it's not going to cover everything, right? For example, it's not going to cover, it's not going to prevent them from transferring IP, right? So we need legal rules for that. rules, it can appoint an emergency supervisor and this person is authorized under both statute and contract to come in, sue in the name of the DAO, investigate, hold people responsible, remove people who broke the rules, that sort of thing. It's kind of like a nuclear option on the off-chain legal side. Amendments, right? This would be a way that everything could be rubbed, right? If the board of directors has the authority to amend the bylaws and the bylaws are the things that say, hey, use the IP to the benefit of LidoDAO or whatever, well, that's a potential big end run, right? They could just amend it and expand it or whatever. So you need a rule that says any amendment also requires like a DAO vote. Or it could be the vote of some other multi-sig or some other foundation entity or whatever, right? But the point is you trust minimize it. And kind of like the last technique is like people, if these boards are going to be entering into legal agreements with people, the broader community probably wants transparency on that. So one thing we're doing is what we call Ricardian triplers. This has a technical definition, which I don't have time to give you right now, but the basic idea is, like, you can have a standard agreement, and if someone is signing up to the multisig, well, they would just sign this on-chain, and the variables are literally instantiated on-chain, right? So anyone could look at the chain and reconstruct. They could look at the chain plus the IPFS hash of this agreement, which would have been in the function call, and they can know exactly what agreements this has and who agreed to them and who signed it. So that's really it. One kind of like big meme I will just give you guys that I wasn't able to fit into this very short presentation is like think about the modular trend in blockchains generally, right? You have these big, highly decentralized, highly autonomous L1s. And then you have L2s that are more centralized, but also sort of like more expendable, right? And they have feedback loops with the L1. What have we just described with Borgs and DAOs? Same thing, right? It's the same exact trend. We now have modular designs. You can have a DAO that's surrounded by a bunch of Borgs, just like you could have Ethereum that's surrounded by a bunch of L2s, right? So there's this nice parallelism there. And that's really it. Awesome, Gabriel. Thank you so much. We have time for one question. So who wants to go and be the lucky person? One question for Gabriel. Here, please. The microphone. It's coming to you. It's coming to you. Gabriel, thank you very much for the presentation. I would love to have it because there is lots of valuable stuff. My question is that do you think if there will be a market for the Borgs, for instance, like if the different organizations could like shop for different Borgs that provide certain functions to it? Yeah, absolutely. I think there could be like even a market for like the implants, right? Like you can just add and remove implants as you need them as your organization evolves. And we talked about the DAO adjacent ones here, but actually I think the same approach makes sense for any type of entity, right? Your ordinary corporation, well, the board of directors could be a safe, the stockholders can be like a tokenized dow with like tokenized shares that vote and everything could be much more transparent and in my opinion efficient right because right now if you do um like a like a board of directors resolution let's it's called an action by written consent in delaware well that's saying something should be done or it's authorizing something to happen, but it doesn't in one and the same moment actually cause the transaction to happen. But if your written consents are safe signatures, and it's authorizing sending the money somewhere, in one and the same action of approving it, you're also doing it, right? So it's just obvious to me that it's much more efficient and much more powerful, much more composable, all those things. And I think we will have, yeah, marketplaces that have these implants, marketplaces that have Borgs. And if they're all on the same standard, it actually makes them much easier to do deals with each other. Like imagine a merger of two Borg-ed up corporations where the tokenized shares are on the same standard so that literally you could just call a function and one one set of shares merges into the other right on chain so that's the kind of stuff we're trying to build at my company metal x thank you so much please giving a great applause i appreciate that gabriel",
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731402000000,
- "slot_end": 1731403800000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1Pq-UfROf_3nVsy2VhJLpxOcTmyPsVPQsHMIH4SZRIfY",
+ "slot_start": 1731393000000,
+ "slot_end": 1731394800000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1m4BLa2dYtnZhDK4AVI7x-ufBecnidvE3pGBZchBa82k",
"resources_slides": null,
"speakers": [
- "gabriel-shapiro"
+ "lefteris-karapetsas"
]
},
"vector": [
@@ -186608,11 +186223,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -187251,12 +186863,12 @@
0,
0,
2,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -187304,6 +186916,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -187387,7 +187000,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -187710,16 +187322,16 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -187732,53 +187344,44 @@
},
{
"session": {
- "id": "daos-unmasked-the-hard-truths-behind-the-hype",
- "sourceId": "ZSSKBL",
- "title": "DAOs Unmasked: The Hard Truths Behind the Hype",
- "description": "In this talk we will see what a DAO is, what its not and face some hard truths about DAOs and how they are used today.\r\n\r\nDoes a DAO stand for Discord Administered Organization? Is a DAO just a discord chat and a multisig?\r\n\r\nIs a DAO a way for your company to have 2 cap tables, one for your and your investors and one for your community?\r\n\r\nAre DAOs a face for a Cayman Islands foundation which uses decentralization theater to shift liability?\r\n\r\nAre DAOs a way to sidestep regulations?\r\n\r\nLet's find out!",
- "track": "Coordination",
- "type": "Talk",
+ "id": "dare-to-be-solo-staking",
+ "sourceId": "ZMSNHW",
+ "title": "Dare to be Solo Staking",
+ "description": "I have been solo staking on my home computer since the very first day of the beacon chain. It's been a challenging journey, and I anticipate it will remain so in the coming years. This talk will delve into the time, financial, and technical commitments required for solo staking. It aims to provide a practical overview of the solo staker experience from an Ethereum enthusiast's perspective. I will highlight what is keeping us from a wider solo staking community.",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
"expertise": "Beginner",
"audience": "Community",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Coordination",
- "DAO",
- "Governance",
- "Regulation",
- "Coordination",
- "DAO",
- "Governance"
- ],
"keywords": [
- "Decentralization Theater",
- "Regulation"
+ "staking"
+ ],
+ "tags": [
+ "Staking",
+ "Home staking",
+ "Best Practices",
+ "Public good",
+ "Best Practices",
+ "Home staking",
+ "Public good"
],
- "duration": 1670,
"language": "en",
- "sources_swarmHash": "ecced45caf16ee62282cfbd6014f1bbf67c2b02c548c9d1fee650b8fc8ba5a2c",
- "sources_youtubeId": "pdlMrmUxpSg",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731393000000,
- "slot_end": 1731394800000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1m4BLa2dYtnZhDK4AVI7x-ufBecnidvE3pGBZchBa82k",
- "resources_slides": null,
"speakers": [
- "lefteris-karapetsas"
- ]
+ "jerome-de-tychey"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731642000000,
+ "slot_end": 1731642600000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1YmHz7J7_ErPzoGv9lX-paIBhxZrCFEk_NqqiRA-wNk8"
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -187786,8 +187389,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -187987,9 +187588,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -188556,6 +188157,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -188610,6 +188212,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -188623,12 +188226,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -188654,6 +188255,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -188682,9 +188284,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -189110,45 +188709,54 @@
},
{
"session": {
- "id": "dare-to-be-solo-staking",
- "sourceId": "ZMSNHW",
- "title": "Dare to be Solo Staking",
- "description": "I have been solo staking on my home computer since the very first day of the beacon chain. It's been a challenging journey, and I anticipate it will remain so in the coming years. This talk will delve into the time, financial, and technical commitments required for solo staking. It aims to provide a practical overview of the solo staker experience from an Ethereum enthusiast's perspective. I will highlight what is keeping us from a wider solo staking community.",
- "track": "Core Protocol",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "dark-daos-and-private-coordination",
+ "sourceId": "SX8B9E",
+ "title": "Dark DAOs and Private Coordination",
+ "description": "Dark DAOs allow for undetectable private coordination and are feasible to launch in Ethereum today. In this talk, I will introduce Dark DAOs, highlight applications that should be aware of their possibility, and point to the ways they can be harnessed as mechanisms for both prosocial and antisocial coordination. I will also discuss how the encumbrance of keys utilized by Dark DAOs can generalize. I will introduce Proofs of Complete Knowledge as an available countermeasure.",
+ "track": "Coordination",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "staking"
- ],
"tags": [
- "Staking",
- "Home staking",
- "Best Practices",
- "Public good",
- "Best Practices",
- "Home staking",
- "Public good"
+ "Coordination",
+ "DAO",
+ "Privacy",
+ "dark",
+ "Coordination",
+ "DAO",
+ "Privacy"
],
- "language": "en",
- "speakers": [
- "jerome-de-tychey"
+ "keywords": [
+ "encumbrance",
+ "TEE",
+ "Dark DAO"
],
+ "duration": 1515,
+ "language": "en",
+ "sources_swarmHash": "a97c78c1b59811eb08440fb9b149c05cd099f82a29ca38cecae87b77c00ab27e",
+ "sources_youtubeId": "iU-2dwVVagk",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67335b2b3a168eb53591f192.vtt",
+ "transcript_text": " All right, hey everyone. So I'm Sarah Allen and today I am going to talk about dark DAOs and private coordination. So my goal today is that I will first introduce the technical concepts that you need to know to understand dark DAOs. I'll give a state of knowledge on the research that's been done since they were identified in 2018 till present. I will introduce some recent research contributions and then I'll talk about active mitigations for projects that may want to proactively defend against dark DAOs. So first up let's talk about private keys. So private keys are must be kept secret to be secure. They're assumed to be held by one person or entity. Any signature given with a private key is assumed to be created by its owner. And anything signed is assumed to be signed with that owner's consent. So the assumption here, baked into many of our modern systems, is that private keys are exclusively held and used by their owner. And because of this, the assumption that a private key is equivalent to an identity is often made. But what if an owner could share or rent the right to sign with their key? In that case, private key could no longer be used instead of identity. And this is the case with encumbrance. So what is encumbrance? A secret key can be generated in a trusted execution environment and the key then continues to live in that TEE. The TEE can then be used to apply complex policies to that private key and to its use going forward. So here you can see a user who's generated a private key within a trusted execution environment. They then have access to that key, but their access is going to be mediated by any programs that are being run by the TEE. So in the presence of TEEs and encumbered accounts, while the private key must still be kept secret to be secure, that's the role of the trusted execution environment in the case of an encumbered key. You can no longer assume that that key is held by one person or entity. You can no longer assume that any signature that has been made was done by that person or with their consent. So the single entity address ownership assumption is what's broken by encumbrance and given that that assumption is made in many current blockchain systems this has wide-ranging implications. The implications of this broken assumption were first identified toward DAO voting in this 2018 post on-chain vote buying and the rise of darkOs, by Philip Dyan, Tyler Kell, Ian Myers, and Ari Jules. And in this post, they identified a dark DAO as a decentralized cartel that buys on-chain votes opaquely, so in the dark. Potentially nobody, not even the creator of a dark DAO, can determine the total number of participants, the total amount pledged, so the treasury of the dark DAO, and the precise logic of that dark DAO. So here you can see the model of a dark DAO. So you have a collection of voters who've all generated encumbered accounts. They've pooled their encumbered keys. And now a program can be run across all of those keys together. That's the dark DAO. The program can be this sort of automated vote buying in which an adversary can bid for the right to run the program across all of their votes. So it is this coordination trustlessly done through trusted execution environments that could be coordinated to vote in DAOs. So that 2018 blog post suggested the concept of dark DAOs, but it became more concrete in 2023 in DAO decentralization, voting block entropy, bribery, and dark DAOs. This paper was co-led by James Austin and Andres Fabreja. I contributed, as did Kushal Babal, Mahim Nikhelkar, and Ari Jules. And this paper had two main contributions. So the first was a new concept of decentralization in DAOs, which we call VIBE, or voting block entropy. VIBE conceptualizes decentralization in DAOs as the blocks of voters with aligned utility functions. And so that contribution aimed to model decentralization in DAOs as something that would be sensitive to things like private coordination through dark DAOs. The second main contribution of the paper was this model of a dark DAO led by James Austin. So we were able to create a prototype of a dark DAO that could currently be used in Ethereum DAOs. So we did two different prototypes. This is the first one. And I'll provide a research list at the end of this talk and also share it on Twitter if you're interested in checking out the repository. But this first one is a set of contracts. So they're Solidity smart contracts, which could be applied to Ethereum. They use Oasis, which is a trusted execution environment blockchain as their backend. And you can see here that they could be applied. So the policy that I've highlighted here could be applied for voting in snapshot. Secondly we created something called a dark DAO light. So this you can think of this as sort of liquid staking for governance votes and this is more user friendly because users wouldn't need to encumber their own keys rather they would deposit their voting tokens in a smart contract which would then give them something we called the DD token, which is a token that would have the value of their votes, plus the value of any bribes paid to participants in the dark DAO. And we have a demo available here too that you can find in the research list. And these two prototypes proved the sort of proximate and practical reality of dark DAOs, although we're not aware of any currently operating. We posit that this is because dark DAOs are an effective coordination tool in a truly decentralized DAO. And so the current means of sort of collusion and coercion or private coordination in DAOs haven't yet needed dark DAOs to support them. However, the goal in releasing these prototypes was to highlight that this is a threat that DAOs should start thinking about and taking proximate steps against. And I'll point out those later in this talk. But in the creation of that sort of dark DAO light, it occurred to us that actually what's happening here, this encumbering of private keys, has much broader implications than dark DAOs themselves. And so we call that liquefaction. Liquefaction is an encumbered wallet platform which allows users to attach rich multi-use policies to accounts. It enables the credentials and assets of a single end user address to be freely rented, shared or pooled. And it accomplishes these things privately with no direct on chain traces. So broadly it enables the transfer of things thought to be non transferable. So what is impacted by liquefaction, this broader tool? So first let's talk about private DAOs. And the important thing to note when going through these impacted areas is that liquefaction is this general tool that has both pro-social and anti-social consequences. So this first one is a particularly pro-social one, which is that you could create a DAO that is privacy preserving, so its treasury is not known and its participants are not known on chain. This would have been particularly helpful in the case of Constitution DAO. So Constitution DAO was a DAO that was coordinated to try to pool funds to participate in an auction for a copy of the U.S. Constitution. Constitution DAO did not win that auction. It's not possible to know whether they could have won the auction it had they had a privacy preserving Dow however participating in a public auction with your max bid known aka your Treasury size certainly put them at a disadvantage so had they incorporated as a private Dow they may have been more competitive as a group next up quadratic voting and quadratic funding so liquefaction and encumbrance are important things to note for system designers who are considering doing quadratic voting or quadratic funding, even if they do have strong identity systems. This is important because, so quadratic voting, quadratic funding, as I expect many of you in the room know since we're in the DAO track, these are systems designed to subvert tyranny of the majority. So they aim to empower many small voices as opposed to direct token voting. However, the problem with empowering many small voices in the case where small voices are able to sell access to their accounts is that it would allow a whale to potentially square their voting power or their funding power. So if a whale were to separate their account funds across many small accounts and those accounts were encumbered, so they're able to do that in a way where they can trust that they can vote on behalf of those accounts and they can vote with their own token weight from those accounts and then return the funds to themselves after the election, that whale is able to command much more power than in direct token voting. So definitely something to be aware of for people designing those systems. Next up, soulbound tokens. So soulbound tokens are designed to be non-transferable NFTs. By being non-transferable, they're supposed to have this special sense of identity that sits with that user account for its whole lifespan. However, if a Soulbound token is sent to an encumbered account, then the user who owns that account is able to rent out, fractionalize, or potentially sell the access to that Soulbound token while retaining the Soulbound token in their initial account. So they won't have broken the policy in any detectable on-chain way for that soulbound token but that soulbound token will no longer be non-transferable in practice next up rights to airdrops and activity-based rewards so rights to airdrops um are often or can be predicted for accounts ahead of time. However, there has not been a way, to my knowledge, for this sort of speculator class to arrive for individual airdrop rights. But if individuals encumber their accounts, to which they may receive future airdrops, then they could potentially sell the right to receive airdrops to their account in a way that is trust minimized for these speculators who might buy those rights, but would unlock liquidity for those users at an earlier date than the airdrop itself. And then similarly, activity-based rewards. So decentralized exchanges and some other services provide, for instance, better trading fees for users who do a lot of volume, do a lot of trading, have a long history. An encumbered account could be shared across many users, even those who don't know or trust one another. And so they could sort of pool their activity to get these rewards like lower trading fees together on their accounts. Next up, dusting attacks. So dusting attacks are the sending of potentially unwanted tokens to many addresses. At least to current date, there isn't a way to prove whether or not you have custody of those funds. So they've been sent to you, now your account is potentially tainted. However, using an encumbered wallet, you can prove whether or not you have access to those tokens, and whether or not you truly hold in custody them, so you could provide a proof that you do not actually own or command those tainted tokens. Next up, locked tokens. So when projects issue tokens for grants to investors to early project participants, often those tokens are locked and have a vesting period, and that can be automatically enforced. However, if they're deposited to encumbered accounts, then individuals could credibly sell the right to those future unlocked tokens while not transferring them from their current accounts. This might be desirable for those who don't want to show an on-chain transfer that they've done this, but do want to unlock liquidity or decrease their stake in a protocol earlier on. Next up, on-chain and off-chain transacting. So transactions among encumbered accounts could bend what we currently think of in terms of what needs to happen on-chain versus off-chain. So for instance a set of encumbered accounts could trade with one another but send only a few transactions on-chain or messages on-chain that they are making transfers among themselves. So this would be an interesting strategy to minimize gas. Next up, multisigs. So in a multisignature scheme, if you encumber one member of that multisig, you could do two interesting things. So the first would be you could add additional security by creating this multisig of multisigs that wouldn't be visible on chain. So you could have many signers not identifiable on chain for this multisig who need to command each visible signature. But the second is also a more sinister one. So an adversary could potentially rent the use of a signature as part of a multisig. And then lastly, allow lists. So it's much more complicated to think about what it would mean to create a binding allow list in a world where users can trustlessly share accounts through encumbrance. And there are more potential implications, both prosocial and antisocial, in our upcoming liquefaction paper. So stay tuned if you're interested in more. So now that I've gone through the many potential implications of encumbrance, I'm sure many are wondering, what should one do in settings where you don't want undetected encumbrance? You want to be sure that these things are not possible. So you'll need to use something called a proof of complete knowledge. This is a cryptographic technique that was created by Mahim Nakelkar, Kushal Babal, Phil Diane, James Austin, Vitalik Buterin, and Ari Jules. And a proof of complete knowledge is a way to show fully unencumbered knowledge of a secret. It goes beyond proving that the key... It does this by proving that the key, it does this by proving that the key has been leaked over an insecure channel and it can be done with either a TE or an ASIC. The TEE version of this is possible to do on the local enclave in an Android mobile phone so that's the more likely one to be applied. So where is this all taking us? Encumbrance in TEs breaks assumptions underlying blockchain systems, and additional measures like CK will need to be added to systems that want to ensure that a signer is the account owner, is also a single individual or entity. And the most practical implementation of CK relies on TEEs. So in summary, undetectable encumbrance is already practical, and the defense against undetectable encumbrance will likely rely on TEEs. So what's next? We'll need to crowdsource a more complete list of systems that rely on assumptions that are broken by encumbrance. We'll need to spread awareness that the signer may not be the account owner in current systems and designed to either accept this or take measures against it. For those wishing to take measures against it, they'll need to adopt CK. And we need to focus community effort on deep research on TEEs to develop an open TEE for our open systems. And this one's important. It's a big project, and we're just now starting. So if you're interested in getting involved here, I would suggest that you head to the Flashbots forum. We call this project Trustless TEE. And there are some posts already available on the writings website where you can check out those sort of early understandings of what's going to be involved in developing truly open hardware. And I have a resource list here with clickable links to all of the papers and posts that I've discussed today. I will also be sharing this on Twitter, and I believe the organizers are sharing the slides as well. All right, thank you for your time and attention, and thank you so much to the organizers. Thank you so much, Sarah, for all of this. And people, you haven't started asking questions with the QR code. So before someone starts placing questions, there's someone who wants to have the microphone and start breaking the ice with the questions. There. Cool. I'm so sorry for the very basic question, but just to make sure, encumbrance is basically like lending someone your ID to get into a club or something and then just getting that ID back. Is that about accurate? You can think of it as lending somebody your, that is like one policy that a trusted execution environment could enforce here. So you can think about it as sort of lending your credentials similarly to lending your ID, except that it's trustless. So you could lend anybody your ID anywhere in the world in a way where you don't need to know or trust them, and it's automatically enforced, and you can be sure you'll get it back exactly when they've said they were going to give it back to you as opposed to having any doubt or trust. Nice. We have the first question here in the queue area. So what are their most likely dark DAOs now? So I'm not sure, and I don't want to give an answer as though I am sure. My assumption is that there are not dark daos currently operating. The places where dark daos might be more credible threats are places that are the most decentralized, where coordinating voters to have a sort of overwhelming share of power would not be practical to do person to person anymore. So if you think about daos that are centralized, where a few whales might be able to coordinate personally to ensure that a vote goes in their direction, I would not expect that to be a good candidate for a dark DAO currently. If you think about a system that is truly and ideally decentralized where it becomes totally impossible to coordinate people individual to individual to get this overwhelming share of votes that you need to pass something, that's when a dark DAO starts to become relevant. So it's as our systems reach these ideals that we've set for them for decentralization is when we need to both be on the lookout for these. Fantastic. And we have our next question is, is there an example implementation of CK? Yes, there is. So there are a couple of example implementations of CK. You can find them on GitHub linked through the paper that I have shared in the resource list. One of them relies on an ASIC. One requires on Intel SGX, which is a trusted execution environment. And one relies on the enclave that is in an Android mobile phone. It's likely also possible to develop this for the enclave that's within iOS or an Apple device, but it hasn't yet been built. Awesome. Someone having problems with the QR code and wanting to ask a question? We still have time for more questions? Who wants to go ahead? Ah, we have another question. Seems like it's a way for CBDCs on public blockchains. I'm not sure I understand the question. A CBDC, a central bank digital currency, is think, probably unlikely to want the particular set of privacy properties that a dark DAO has. But I'd be interested to hear more if someone wants to elaborate. Please, the person who wrote the question wants to elaborate. So it seems like a way for centralized entities to control multiple wallets and to implement like a soft version of CBDC on a public blockchain. So you mean it's a way for an entity who wants to control some aspect of a DAO or a public blockchain to seize control in an undetectable manner? Yeah, yeah. So I would say it's likely a large coordination and building lift to do this currently. Like, I would be surprised if this is currently ongoing and we're unaware of it. It's hard to speculate on where dark DAOs will go over time, or if they will become this sort of relevant problem. I could imagine them being tools for useful private coordination for groups that have a lot of funds to deploy. So I can see your concern, but it's not one that I've considered. Thank you. Okay, awesome. We don't have more questions. Yes, we have one more question. That side. Hi, thanks for the presentation. I had one question. What would be the difference between an oligopoly and, say, dark DAOs? Because I feel the difference would be between legal and illegal. Is that correct? So I would say that the dark DAO does not have to be lasting. So it would depend on the structure it takes on the program that's being used. It would be possible for a dark DAO to be launched for just a single vote. So somebody coordinates a dark DAO and then somebody launches a program that only coordinates a group of voters or bribes a specific group of voters for that particular round of voting. Then once the vote that is relevant to the whale that's paying them is over, then the program is changed. And so those voters that had been aligned in that earlier dark DAO are no longer aligned. So I think the, as I understand oligopolies, a dark DAO might create a circumstance that looks similarly centralized for the round in which that program is operating, but it would be less lasting than an oligopoly in like a token system. No? Number three. but it would be less lasting than an oligopoly in like a token system. So it's kind of like a bot network, but it can be turned on and off. I'm struggling to understand what the incentives of creating a bot network is and then for just one proposal and then turning it off. Unless, of course, that proposal means the collapse of the DAO, right? So I think it's possible that one would be created and then immediately dissolved. But it would be likelier, my assumption would be that one would be created, but then it would have different programs, so different sort of adversaries who want to buy its weight for different votes. So rather than one individual who's consistently commanding this network over time, it might be more temporary based on who has the highest utility from that particular vote. Yes. Hi. One possible solution to the problem could be using soulbound tokens with a liveness check at the point where you need to vote or, for instance, claim your airdrop. So you can't really sell or rent access to your private key if you need to prove that you're still the same person at that time. So it would depend on how you structured it, but I think you still actually would need to add proof of complete knowledge to that Soulbound token, so the sort of liveness check would need to be inclusive of this proof of complete knowledge, because otherwise somebody who wanted to restrict the ability to vote in an election could permission it so that you could still succeed at that liveness check, so provide the proof necessary from the Soulbound Token account that it's still sitting there and alive, but then limit the way in which you can vote in that election. So it could still say, you can produce a liveness check, but then you can only vote yes. But that would be built into the rules of the DAO? That would be built into the program that would be command into the rules of the DAO? That would be built into the program that would be commanding the use of the secret keys within the enclaves. So the dark DAO would create this set of rules by which you could cast your votes, but you can do anything else from your account. So what you need to prove is actually that full unencumbered access to the secret key. Yeah, okay, I think I see what you mean. Okay, people, thank you so much. Let's please give a great applause to Sarah.",
"eventId": "devcon-7",
- "slot_start": 1731642000000,
- "slot_end": 1731642600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1YmHz7J7_ErPzoGv9lX-paIBhxZrCFEk_NqqiRA-wNk8"
+ "slot_start": 1731405600000,
+ "slot_end": 1731407400000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1t0x6tAJgffLnu_2grB_zh1mp_RzOCOpsI9MX1oYUMlY",
+ "resources_slides": null,
+ "speakers": [
+ "sarah-allen"
+ ]
},
"vector": [
0,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -189156,6 +188764,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -189356,9 +188965,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -189926,7 +189535,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -189981,7 +189589,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -189996,6 +189603,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -190004,13 +189612,13 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -190024,7 +189632,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -190050,6 +189657,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -190132,6 +189740,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -190454,6 +190063,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -190465,9 +190075,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -190478,51 +190085,37 @@
},
{
"session": {
- "id": "dark-daos-and-private-coordination",
- "sourceId": "SX8B9E",
- "title": "Dark DAOs and Private Coordination",
- "description": "Dark DAOs allow for undetectable private coordination and are feasible to launch in Ethereum today. In this talk, I will introduce Dark DAOs, highlight applications that should be aware of their possibility, and point to the ways they can be harnessed as mechanisms for both prosocial and antisocial coordination. I will also discuss how the encumbrance of keys utilized by Dark DAOs can generalize. I will introduce Proofs of Complete Knowledge as an available countermeasure.",
- "track": "Coordination",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "id": "dark-winter-why-the-risk-of-unnatural-pandemics-is-an-existential-threat",
+ "sourceId": "7QAKPP",
+ "title": "Dark winter: why the risk of unnatural pandemics is an existential threat",
+ "description": "The past history of pandemics and biological attacks, lab accidents and epidemics show a recurrent theme of denial, silence and cover-up around unnatural epidemics and the powerful vested interests at play. Quantum advances in genetic engineering and synthetic biology may lead to a future where resurrection of extinct viruses are the norm. The risk of unnatural pandemics is greater than ever and poses an existential threat. Early warnings of epidemics through OSINT can help mitigate the risk.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Coordination",
- "DAO",
- "Privacy",
- "dark",
- "Coordination",
- "DAO",
- "Privacy"
- ],
"keywords": [
- "encumbrance",
- "TEE",
- "Dark DAO"
+ "Biosafety"
+ ],
+ "tags": [
+ "Collective Intelligence",
+ "Public good",
+ "Security"
],
- "duration": 1515,
"language": "en",
- "sources_swarmHash": "a97c78c1b59811eb08440fb9b149c05cd099f82a29ca38cecae87b77c00ab27e",
- "sources_youtubeId": "iU-2dwVVagk",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67335b2b3a168eb53591f192.vtt",
- "transcript_text": " All right, hey everyone. So I'm Sarah Allen and today I am going to talk about dark DAOs and private coordination. So my goal today is that I will first introduce the technical concepts that you need to know to understand dark DAOs. I'll give a state of knowledge on the research that's been done since they were identified in 2018 till present. I will introduce some recent research contributions and then I'll talk about active mitigations for projects that may want to proactively defend against dark DAOs. So first up let's talk about private keys. So private keys are must be kept secret to be secure. They're assumed to be held by one person or entity. Any signature given with a private key is assumed to be created by its owner. And anything signed is assumed to be signed with that owner's consent. So the assumption here, baked into many of our modern systems, is that private keys are exclusively held and used by their owner. And because of this, the assumption that a private key is equivalent to an identity is often made. But what if an owner could share or rent the right to sign with their key? In that case, private key could no longer be used instead of identity. And this is the case with encumbrance. So what is encumbrance? A secret key can be generated in a trusted execution environment and the key then continues to live in that TEE. The TEE can then be used to apply complex policies to that private key and to its use going forward. So here you can see a user who's generated a private key within a trusted execution environment. They then have access to that key, but their access is going to be mediated by any programs that are being run by the TEE. So in the presence of TEEs and encumbered accounts, while the private key must still be kept secret to be secure, that's the role of the trusted execution environment in the case of an encumbered key. You can no longer assume that that key is held by one person or entity. You can no longer assume that any signature that has been made was done by that person or with their consent. So the single entity address ownership assumption is what's broken by encumbrance and given that that assumption is made in many current blockchain systems this has wide-ranging implications. The implications of this broken assumption were first identified toward DAO voting in this 2018 post on-chain vote buying and the rise of darkOs, by Philip Dyan, Tyler Kell, Ian Myers, and Ari Jules. And in this post, they identified a dark DAO as a decentralized cartel that buys on-chain votes opaquely, so in the dark. Potentially nobody, not even the creator of a dark DAO, can determine the total number of participants, the total amount pledged, so the treasury of the dark DAO, and the precise logic of that dark DAO. So here you can see the model of a dark DAO. So you have a collection of voters who've all generated encumbered accounts. They've pooled their encumbered keys. And now a program can be run across all of those keys together. That's the dark DAO. The program can be this sort of automated vote buying in which an adversary can bid for the right to run the program across all of their votes. So it is this coordination trustlessly done through trusted execution environments that could be coordinated to vote in DAOs. So that 2018 blog post suggested the concept of dark DAOs, but it became more concrete in 2023 in DAO decentralization, voting block entropy, bribery, and dark DAOs. This paper was co-led by James Austin and Andres Fabreja. I contributed, as did Kushal Babal, Mahim Nikhelkar, and Ari Jules. And this paper had two main contributions. So the first was a new concept of decentralization in DAOs, which we call VIBE, or voting block entropy. VIBE conceptualizes decentralization in DAOs as the blocks of voters with aligned utility functions. And so that contribution aimed to model decentralization in DAOs as something that would be sensitive to things like private coordination through dark DAOs. The second main contribution of the paper was this model of a dark DAO led by James Austin. So we were able to create a prototype of a dark DAO that could currently be used in Ethereum DAOs. So we did two different prototypes. This is the first one. And I'll provide a research list at the end of this talk and also share it on Twitter if you're interested in checking out the repository. But this first one is a set of contracts. So they're Solidity smart contracts, which could be applied to Ethereum. They use Oasis, which is a trusted execution environment blockchain as their backend. And you can see here that they could be applied. So the policy that I've highlighted here could be applied for voting in snapshot. Secondly we created something called a dark DAO light. So this you can think of this as sort of liquid staking for governance votes and this is more user friendly because users wouldn't need to encumber their own keys rather they would deposit their voting tokens in a smart contract which would then give them something we called the DD token, which is a token that would have the value of their votes, plus the value of any bribes paid to participants in the dark DAO. And we have a demo available here too that you can find in the research list. And these two prototypes proved the sort of proximate and practical reality of dark DAOs, although we're not aware of any currently operating. We posit that this is because dark DAOs are an effective coordination tool in a truly decentralized DAO. And so the current means of sort of collusion and coercion or private coordination in DAOs haven't yet needed dark DAOs to support them. However, the goal in releasing these prototypes was to highlight that this is a threat that DAOs should start thinking about and taking proximate steps against. And I'll point out those later in this talk. But in the creation of that sort of dark DAO light, it occurred to us that actually what's happening here, this encumbering of private keys, has much broader implications than dark DAOs themselves. And so we call that liquefaction. Liquefaction is an encumbered wallet platform which allows users to attach rich multi-use policies to accounts. It enables the credentials and assets of a single end user address to be freely rented, shared or pooled. And it accomplishes these things privately with no direct on chain traces. So broadly it enables the transfer of things thought to be non transferable. So what is impacted by liquefaction, this broader tool? So first let's talk about private DAOs. And the important thing to note when going through these impacted areas is that liquefaction is this general tool that has both pro-social and anti-social consequences. So this first one is a particularly pro-social one, which is that you could create a DAO that is privacy preserving, so its treasury is not known and its participants are not known on chain. This would have been particularly helpful in the case of Constitution DAO. So Constitution DAO was a DAO that was coordinated to try to pool funds to participate in an auction for a copy of the U.S. Constitution. Constitution DAO did not win that auction. It's not possible to know whether they could have won the auction it had they had a privacy preserving Dow however participating in a public auction with your max bid known aka your Treasury size certainly put them at a disadvantage so had they incorporated as a private Dow they may have been more competitive as a group next up quadratic voting and quadratic funding so liquefaction and encumbrance are important things to note for system designers who are considering doing quadratic voting or quadratic funding, even if they do have strong identity systems. This is important because, so quadratic voting, quadratic funding, as I expect many of you in the room know since we're in the DAO track, these are systems designed to subvert tyranny of the majority. So they aim to empower many small voices as opposed to direct token voting. However, the problem with empowering many small voices in the case where small voices are able to sell access to their accounts is that it would allow a whale to potentially square their voting power or their funding power. So if a whale were to separate their account funds across many small accounts and those accounts were encumbered, so they're able to do that in a way where they can trust that they can vote on behalf of those accounts and they can vote with their own token weight from those accounts and then return the funds to themselves after the election, that whale is able to command much more power than in direct token voting. So definitely something to be aware of for people designing those systems. Next up, soulbound tokens. So soulbound tokens are designed to be non-transferable NFTs. By being non-transferable, they're supposed to have this special sense of identity that sits with that user account for its whole lifespan. However, if a Soulbound token is sent to an encumbered account, then the user who owns that account is able to rent out, fractionalize, or potentially sell the access to that Soulbound token while retaining the Soulbound token in their initial account. So they won't have broken the policy in any detectable on-chain way for that soulbound token but that soulbound token will no longer be non-transferable in practice next up rights to airdrops and activity-based rewards so rights to airdrops um are often or can be predicted for accounts ahead of time. However, there has not been a way, to my knowledge, for this sort of speculator class to arrive for individual airdrop rights. But if individuals encumber their accounts, to which they may receive future airdrops, then they could potentially sell the right to receive airdrops to their account in a way that is trust minimized for these speculators who might buy those rights, but would unlock liquidity for those users at an earlier date than the airdrop itself. And then similarly, activity-based rewards. So decentralized exchanges and some other services provide, for instance, better trading fees for users who do a lot of volume, do a lot of trading, have a long history. An encumbered account could be shared across many users, even those who don't know or trust one another. And so they could sort of pool their activity to get these rewards like lower trading fees together on their accounts. Next up, dusting attacks. So dusting attacks are the sending of potentially unwanted tokens to many addresses. At least to current date, there isn't a way to prove whether or not you have custody of those funds. So they've been sent to you, now your account is potentially tainted. However, using an encumbered wallet, you can prove whether or not you have access to those tokens, and whether or not you truly hold in custody them, so you could provide a proof that you do not actually own or command those tainted tokens. Next up, locked tokens. So when projects issue tokens for grants to investors to early project participants, often those tokens are locked and have a vesting period, and that can be automatically enforced. However, if they're deposited to encumbered accounts, then individuals could credibly sell the right to those future unlocked tokens while not transferring them from their current accounts. This might be desirable for those who don't want to show an on-chain transfer that they've done this, but do want to unlock liquidity or decrease their stake in a protocol earlier on. Next up, on-chain and off-chain transacting. So transactions among encumbered accounts could bend what we currently think of in terms of what needs to happen on-chain versus off-chain. So for instance a set of encumbered accounts could trade with one another but send only a few transactions on-chain or messages on-chain that they are making transfers among themselves. So this would be an interesting strategy to minimize gas. Next up, multisigs. So in a multisignature scheme, if you encumber one member of that multisig, you could do two interesting things. So the first would be you could add additional security by creating this multisig of multisigs that wouldn't be visible on chain. So you could have many signers not identifiable on chain for this multisig who need to command each visible signature. But the second is also a more sinister one. So an adversary could potentially rent the use of a signature as part of a multisig. And then lastly, allow lists. So it's much more complicated to think about what it would mean to create a binding allow list in a world where users can trustlessly share accounts through encumbrance. And there are more potential implications, both prosocial and antisocial, in our upcoming liquefaction paper. So stay tuned if you're interested in more. So now that I've gone through the many potential implications of encumbrance, I'm sure many are wondering, what should one do in settings where you don't want undetected encumbrance? You want to be sure that these things are not possible. So you'll need to use something called a proof of complete knowledge. This is a cryptographic technique that was created by Mahim Nakelkar, Kushal Babal, Phil Diane, James Austin, Vitalik Buterin, and Ari Jules. And a proof of complete knowledge is a way to show fully unencumbered knowledge of a secret. It goes beyond proving that the key... It does this by proving that the key, it does this by proving that the key has been leaked over an insecure channel and it can be done with either a TE or an ASIC. The TEE version of this is possible to do on the local enclave in an Android mobile phone so that's the more likely one to be applied. So where is this all taking us? Encumbrance in TEs breaks assumptions underlying blockchain systems, and additional measures like CK will need to be added to systems that want to ensure that a signer is the account owner, is also a single individual or entity. And the most practical implementation of CK relies on TEEs. So in summary, undetectable encumbrance is already practical, and the defense against undetectable encumbrance will likely rely on TEEs. So what's next? We'll need to crowdsource a more complete list of systems that rely on assumptions that are broken by encumbrance. We'll need to spread awareness that the signer may not be the account owner in current systems and designed to either accept this or take measures against it. For those wishing to take measures against it, they'll need to adopt CK. And we need to focus community effort on deep research on TEEs to develop an open TEE for our open systems. And this one's important. It's a big project, and we're just now starting. So if you're interested in getting involved here, I would suggest that you head to the Flashbots forum. We call this project Trustless TEE. And there are some posts already available on the writings website where you can check out those sort of early understandings of what's going to be involved in developing truly open hardware. And I have a resource list here with clickable links to all of the papers and posts that I've discussed today. I will also be sharing this on Twitter, and I believe the organizers are sharing the slides as well. All right, thank you for your time and attention, and thank you so much to the organizers. Thank you so much, Sarah, for all of this. And people, you haven't started asking questions with the QR code. So before someone starts placing questions, there's someone who wants to have the microphone and start breaking the ice with the questions. There. Cool. I'm so sorry for the very basic question, but just to make sure, encumbrance is basically like lending someone your ID to get into a club or something and then just getting that ID back. Is that about accurate? You can think of it as lending somebody your, that is like one policy that a trusted execution environment could enforce here. So you can think about it as sort of lending your credentials similarly to lending your ID, except that it's trustless. So you could lend anybody your ID anywhere in the world in a way where you don't need to know or trust them, and it's automatically enforced, and you can be sure you'll get it back exactly when they've said they were going to give it back to you as opposed to having any doubt or trust. Nice. We have the first question here in the queue area. So what are their most likely dark DAOs now? So I'm not sure, and I don't want to give an answer as though I am sure. My assumption is that there are not dark daos currently operating. The places where dark daos might be more credible threats are places that are the most decentralized, where coordinating voters to have a sort of overwhelming share of power would not be practical to do person to person anymore. So if you think about daos that are centralized, where a few whales might be able to coordinate personally to ensure that a vote goes in their direction, I would not expect that to be a good candidate for a dark DAO currently. If you think about a system that is truly and ideally decentralized where it becomes totally impossible to coordinate people individual to individual to get this overwhelming share of votes that you need to pass something, that's when a dark DAO starts to become relevant. So it's as our systems reach these ideals that we've set for them for decentralization is when we need to both be on the lookout for these. Fantastic. And we have our next question is, is there an example implementation of CK? Yes, there is. So there are a couple of example implementations of CK. You can find them on GitHub linked through the paper that I have shared in the resource list. One of them relies on an ASIC. One requires on Intel SGX, which is a trusted execution environment. And one relies on the enclave that is in an Android mobile phone. It's likely also possible to develop this for the enclave that's within iOS or an Apple device, but it hasn't yet been built. Awesome. Someone having problems with the QR code and wanting to ask a question? We still have time for more questions? Who wants to go ahead? Ah, we have another question. Seems like it's a way for CBDCs on public blockchains. I'm not sure I understand the question. A CBDC, a central bank digital currency, is think, probably unlikely to want the particular set of privacy properties that a dark DAO has. But I'd be interested to hear more if someone wants to elaborate. Please, the person who wrote the question wants to elaborate. So it seems like a way for centralized entities to control multiple wallets and to implement like a soft version of CBDC on a public blockchain. So you mean it's a way for an entity who wants to control some aspect of a DAO or a public blockchain to seize control in an undetectable manner? Yeah, yeah. So I would say it's likely a large coordination and building lift to do this currently. Like, I would be surprised if this is currently ongoing and we're unaware of it. It's hard to speculate on where dark DAOs will go over time, or if they will become this sort of relevant problem. I could imagine them being tools for useful private coordination for groups that have a lot of funds to deploy. So I can see your concern, but it's not one that I've considered. Thank you. Okay, awesome. We don't have more questions. Yes, we have one more question. That side. Hi, thanks for the presentation. I had one question. What would be the difference between an oligopoly and, say, dark DAOs? Because I feel the difference would be between legal and illegal. Is that correct? So I would say that the dark DAO does not have to be lasting. So it would depend on the structure it takes on the program that's being used. It would be possible for a dark DAO to be launched for just a single vote. So somebody coordinates a dark DAO and then somebody launches a program that only coordinates a group of voters or bribes a specific group of voters for that particular round of voting. Then once the vote that is relevant to the whale that's paying them is over, then the program is changed. And so those voters that had been aligned in that earlier dark DAO are no longer aligned. So I think the, as I understand oligopolies, a dark DAO might create a circumstance that looks similarly centralized for the round in which that program is operating, but it would be less lasting than an oligopoly in like a token system. No? Number three. but it would be less lasting than an oligopoly in like a token system. So it's kind of like a bot network, but it can be turned on and off. I'm struggling to understand what the incentives of creating a bot network is and then for just one proposal and then turning it off. Unless, of course, that proposal means the collapse of the DAO, right? So I think it's possible that one would be created and then immediately dissolved. But it would be likelier, my assumption would be that one would be created, but then it would have different programs, so different sort of adversaries who want to buy its weight for different votes. So rather than one individual who's consistently commanding this network over time, it might be more temporary based on who has the highest utility from that particular vote. Yes. Hi. One possible solution to the problem could be using soulbound tokens with a liveness check at the point where you need to vote or, for instance, claim your airdrop. So you can't really sell or rent access to your private key if you need to prove that you're still the same person at that time. So it would depend on how you structured it, but I think you still actually would need to add proof of complete knowledge to that Soulbound token, so the sort of liveness check would need to be inclusive of this proof of complete knowledge, because otherwise somebody who wanted to restrict the ability to vote in an election could permission it so that you could still succeed at that liveness check, so provide the proof necessary from the Soulbound Token account that it's still sitting there and alive, but then limit the way in which you can vote in that election. So it could still say, you can produce a liveness check, but then you can only vote yes. But that would be built into the rules of the DAO? That would be built into the program that would be command into the rules of the DAO? That would be built into the program that would be commanding the use of the secret keys within the enclaves. So the dark DAO would create this set of rules by which you could cast your votes, but you can do anything else from your account. So what you need to prove is actually that full unencumbered access to the secret key. Yeah, okay, I think I see what you mean. Okay, people, thank you so much. Let's please give a great applause to Sarah.",
- "eventId": "devcon-7",
- "slot_start": 1731405600000,
- "slot_end": 1731407400000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1t0x6tAJgffLnu_2grB_zh1mp_RzOCOpsI9MX1oYUMlY",
- "resources_slides": null,
"speakers": [
- "sarah-allen"
- ]
+ "raina-macintyre"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731568800000,
+ "slot_end": 1731569700000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/16BGl6R_AIgh1Fz7_yHfLOgt8VeqXZacUFlcwQz9qvOU"
},
"vector": [
0,
+ 6,
0,
0,
0,
@@ -190533,7 +190126,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -190736,8 +190328,8 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -191271,6 +190863,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -191304,6 +190897,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -191375,10 +190969,10 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -191390,7 +190984,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -191429,7 +191022,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -191513,7 +191105,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -191837,9 +191428,6 @@
0,
2,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -191852,50 +191440,52 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "dark-winter-why-the-risk-of-unnatural-pandemics-is-an-existential-threat",
- "sourceId": "7QAKPP",
- "title": "Dark winter: why the risk of unnatural pandemics is an existential threat",
- "description": "The past history of pandemics and biological attacks, lab accidents and epidemics show a recurrent theme of denial, silence and cover-up around unnatural epidemics and the powerful vested interests at play. Quantum advances in genetic engineering and synthetic biology may lead to a future where resurrection of extinct viruses are the norm. The risk of unnatural pandemics is greater than ever and poses an existential threat. Early warnings of epidemics through OSINT can help mitigate the risk.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
+ "id": "darkfi-kills-glowies-intro-to-the-worlds-first-anon-dao-anon-markets-anon-chat-the-coming-regfi-vs-darkfi-split-the-dark-forest-and-secure-freedom-for-sovereign-society",
+ "sourceId": "FKED87",
+ "title": "DarkFi kills glowies: intro to the world's first anon DAO, anon markets, anon chat, the coming RegFi vs DarkFi split, the dark forest and secure freedom for sovereign society.",
+ "description": "The FBI director gave a speech on the \"Going Dark problem\" saying that mass usage of crypto threatens to create dark zones online where law enforcement cannot enter.\r\n\r\nDarkFi created the world's first anon DAO, after our experience on AssangeDAO which raised 55 million and bankrolled Assange's freedom.\r\n\r\nWe have also made the world's strongest anon chat, and the only p2p chat which is actually used. As well as task managers and anon markets. DarkFi delivers.\r\n\r\nFight back and lets gain our freedom!",
+ "track": "Cypherpunk & Privacy",
+ "type": "Talk",
"expertise": "Beginner",
- "audience": "Engineering",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Biosafety"
+ "crypto-anarchy",
+ "agorism"
],
"tags": [
- "Collective Intelligence",
- "Public good",
- "Security"
+ "Privacy",
+ "Anonymity",
+ "ZKP",
+ "agorism",
+ "Anonymity",
+ "Privacy",
+ "ZKP"
],
"language": "en",
"speakers": [
- "raina-macintyre"
+ "amir-taaki"
],
"eventId": "devcon-7",
- "slot_start": 1731568800000,
- "slot_end": 1731569700000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/16BGl6R_AIgh1Fz7_yHfLOgt8VeqXZacUFlcwQz9qvOU"
+ "slot_start": 1731490200000,
+ "slot_end": 1731491400000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1p6CtJjA99UENn3f3VpXSbI_lYWQj6O34OdWgb8FUKiE"
},
"vector": [
- 0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -192101,12 +191691,12 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -192638,7 +192228,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -192666,13 +192255,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -192715,6 +192304,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -192747,7 +192337,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -192756,6 +192345,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -192878,6 +192468,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -193203,12 +192794,12 @@
0,
2,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -193221,46 +192812,44 @@
},
{
"session": {
- "id": "darkfi-kills-glowies-intro-to-the-worlds-first-anon-dao-anon-markets-anon-chat-the-coming-regfi-vs-darkfi-split-the-dark-forest-and-secure-freedom-for-sovereign-society",
- "sourceId": "FKED87",
- "title": "DarkFi kills glowies: intro to the world's first anon DAO, anon markets, anon chat, the coming RegFi vs DarkFi split, the dark forest and secure freedom for sovereign society.",
- "description": "The FBI director gave a speech on the \"Going Dark problem\" saying that mass usage of crypto threatens to create dark zones online where law enforcement cannot enter.\r\n\r\nDarkFi created the world's first anon DAO, after our experience on AssangeDAO which raised 55 million and bankrolled Assange's freedom.\r\n\r\nWe have also made the world's strongest anon chat, and the only p2p chat which is actually used. As well as task managers and anon markets. DarkFi delivers.\r\n\r\nFight back and lets gain our freedom!",
- "track": "Cypherpunk & Privacy",
- "type": "Talk",
+ "id": "data-driven-tokenomics-analyzing-incentives-in-action",
+ "sourceId": "LPDCMK",
+ "title": "Data-Driven Tokenomics: Analyzing Incentives in Action",
+ "description": "This session explores using empirical data to analyse the health of tokenomics, monitoring how incentives impact user behaviours. This is important as we need to start shifting the conversation from pure simulations to data analytics and update token incentives in the same vein.",
+ "track": "Cryptoeconomics",
+ "type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
"keywords": [
- "crypto-anarchy",
- "agorism"
+ "data analytics",
+ "growth analytics",
+ "user behaviour"
],
"tags": [
- "Privacy",
- "Anonymity",
- "ZKP",
- "agorism",
- "Anonymity",
- "Privacy",
- "ZKP"
+ "macro/micro economics",
+ "Tokenomics",
+ "User Research"
],
"language": "en",
"speakers": [
- "amir-taaki"
+ "lisa-jy-tan"
],
"eventId": "devcon-7",
- "slot_start": 1731490200000,
- "slot_end": 1731491400000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1p6CtJjA99UENn3f3VpXSbI_lYWQj6O34OdWgb8FUKiE"
+ "slot_start": 1731484200000,
+ "slot_end": 1731484800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1a7L3Uq6GwbOc7abUc_joXIpX0LM57pFSIKpUmrjx4rU"
},
"vector": [
0,
0,
+ 6,
+ 0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -194033,7 +193622,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -194048,6 +193636,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -194082,7 +193671,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -194091,6 +193679,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -194123,7 +193712,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -194217,6 +193805,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -194247,10 +193836,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -194576,7 +194161,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -194585,44 +194169,48 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "data-driven-tokenomics-analyzing-incentives-in-action",
- "sourceId": "LPDCMK",
- "title": "Data-Driven Tokenomics: Analyzing Incentives in Action",
- "description": "This session explores using empirical data to analyse the health of tokenomics, monitoring how incentives impact user behaviours. This is important as we need to start shifting the conversation from pure simulations to data analytics and update token incentives in the same vein.",
- "track": "Cryptoeconomics",
+ "id": "debug-first-or-regret-later-an-arsenal-of-tools-can-build-solid-ethereum-foundations",
+ "sourceId": "LVVTKU",
+ "title": "Debug First, or Regret Later: an Arsenal of Tools can Build Solid Ethereum Foundations",
+ "description": "Building secure and reliable smart contracts requires a robust testing and debugging arsenal. This talk provides a comprehensive and up-to-date overview of essential tools in the Ethereum ecosystem. Learn how to effectively integrate these tools into your development workflow from the start. We'll explore popular options, their strengths, and how to combine them for maximum efficiency. Discover best practices for writing comprehensive tests, identifying and fixing bugs, and ensuring code quality",
+ "track": "Security",
"type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "expertise": "Intermediate",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "data analytics",
- "growth analytics",
- "user behaviour"
+ "Tooling",
+ "debugging",
+ "testing"
],
"tags": [
- "macro/micro economics",
- "Tokenomics",
- "User Research"
+ "DevEx",
+ "Security",
+ "Best Practices",
+ "Testing",
+ "Best Practices",
+ "DevEx",
+ "Security",
+ "Testing"
],
"language": "en",
"speakers": [
- "lisa-jy-tan"
+ "aellison-cassimiro"
],
"eventId": "devcon-7",
- "slot_start": 1731484200000,
- "slot_end": 1731484800000,
+ "slot_start": 1731656400000,
+ "slot_end": 1731657000000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1a7L3Uq6GwbOc7abUc_joXIpX0LM57pFSIKpUmrjx4rU"
+ "resources_presentation": "https://docs.google.com/presentation/d/1XRh2Y67-uqHjSpr6HxoT0Q9rUneXHLaUjz_9YbFd3SM"
},
"vector": [
- 0,
- 0,
6,
0,
0,
@@ -194838,14 +194426,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -195376,6 +194960,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -195405,6 +194990,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -195417,7 +195004,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -195460,7 +195046,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -195586,7 +195171,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -195616,6 +195200,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -195951,53 +195536,50 @@
0,
0,
0,
+ 0,
+ 0,
0
]
},
{
"session": {
- "id": "debug-first-or-regret-later-an-arsenal-of-tools-can-build-solid-ethereum-foundations",
- "sourceId": "LVVTKU",
- "title": "Debug First, or Regret Later: an Arsenal of Tools can Build Solid Ethereum Foundations",
- "description": "Building secure and reliable smart contracts requires a robust testing and debugging arsenal. This talk provides a comprehensive and up-to-date overview of essential tools in the Ethereum ecosystem. Learn how to effectively integrate these tools into your development workflow from the start. We'll explore popular options, their strengths, and how to combine them for maximum efficiency. Discover best practices for writing comprehensive tests, identifying and fixing bugs, and ensuring code quality",
- "track": "Security",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Developer",
+ "id": "debugging-data-for-ethereum-ethdebugformat-overview-and-project-status",
+ "sourceId": "JLWSZ7",
+ "title": "Debugging data for Ethereum – ethdebug/format Overview and Project status",
+ "description": "Building debuggers for EVM languages is challenging, time-consuming, and brittle because compilers do not provide enough information to enable robust tooling. The **ethdebug format** project, sponsored by Solidity, seeks to address this concern by designing a standards-track collection of schemas for expressing high-level language semantics in connection with low-level machine code.\r\n\r\nPlease attend this talk to learn about the status of this effort and a brief overview of its components.",
+ "track": "Developer Experience",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Tooling",
- "debugging",
- "testing"
+ "Debugging"
],
"tags": [
- "DevEx",
- "Security",
+ "Developer Infrastructure",
+ "Tooling",
"Best Practices",
- "Testing",
+ "debugging",
"Best Practices",
- "DevEx",
- "Security",
- "Testing"
+ "Developer Infrastructure",
+ "Tooling"
],
"language": "en",
"speakers": [
- "aellison-cassimiro"
+ "g-nick-gnidan"
],
"eventId": "devcon-7",
- "slot_start": 1731656400000,
- "slot_end": 1731657000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1XRh2Y67-uqHjSpr6HxoT0Q9rUneXHLaUjz_9YbFd3SM"
+ "slot_start": 1731488400000,
+ "slot_end": 1731490200000,
+ "slot_roomId": "classroom-c",
+ "resources_presentation": "https://docs.google.com/presentation/d/1hKCNu1k-EbMC3GsA0i_-SO8vLwgPTyED9D91FSwTjoU"
},
"vector": [
- 6,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -196210,10 +195792,10 @@
0,
0,
0,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -196744,7 +196326,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -196765,6 +196346,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -196775,8 +196357,6 @@
0,
0,
2,
- 2,
- 0,
0,
0,
0,
@@ -196799,6 +196379,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -197305,13 +196886,13 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -197327,49 +196908,48 @@
},
{
"session": {
- "id": "debugging-data-for-ethereum-ethdebugformat-overview-and-project-status",
- "sourceId": "JLWSZ7",
- "title": "Debugging data for Ethereum – ethdebug/format Overview and Project status",
- "description": "Building debuggers for EVM languages is challenging, time-consuming, and brittle because compilers do not provide enough information to enable robust tooling. The **ethdebug format** project, sponsored by Solidity, seeks to address this concern by designing a standards-track collection of schemas for expressing high-level language semantics in connection with low-level machine code.\r\n\r\nPlease attend this talk to learn about the status of this effort and a brief overview of its components.",
- "track": "Developer Experience",
- "type": "Talk",
- "expertise": "Expert",
- "audience": "Engineering",
+ "id": "debunking-myths-about-building-out-of-sea",
+ "sourceId": "CDVQ7R",
+ "title": "Debunking Myths about Building out of SEA",
+ "description": "South East Asia is home to a burgeoning community of builders and some of the most influential projects in Ethereum. Listen in as SEA founders share their experiences and answer your questions about building out of this corner of the world.",
+ "track": "Real World Ethereum",
+ "type": "Panel",
+ "expertise": "Beginner",
+ "audience": "Local/SEA",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Debugging"
+ "Build",
+ "Myth",
+ "Local"
],
"tags": [
- "Developer Infrastructure",
- "Tooling",
- "Best Practices",
- "debugging",
- "Best Practices",
- "Developer Infrastructure",
- "Tooling"
+ "Local Impact",
+ "SEA",
+ "myths",
+ "SEA"
],
"language": "en",
"speakers": [
- "g-nick-gnidan"
+ "matthew-tan",
+ "harith-kamarul",
+ "tn-lee",
+ "loi-luu"
],
"eventId": "devcon-7",
- "slot_start": 1731488400000,
- "slot_end": 1731490200000,
- "slot_roomId": "classroom-c",
- "resources_presentation": "https://docs.google.com/presentation/d/1hKCNu1k-EbMC3GsA0i_-SO8vLwgPTyED9D91FSwTjoU"
+ "slot_start": 1731646800000,
+ "slot_end": 1731650400000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1SpHoMINj55MzEUWqqO7ToaiDbowMedsSM9tKnMWMaSY"
},
"vector": [
- 0,
- 0,
- 0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -197579,11 +197159,14 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -198133,7 +197716,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -198143,7 +197725,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -198166,7 +197747,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -198355,9 +197935,8 @@
0,
0,
2,
- 0,
- 0,
- 0,
+ 2,
+ 2,
0,
0,
0,
@@ -198677,7 +198256,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -198690,44 +198268,32 @@
0,
0,
0,
+ 0,
+ 2,
0
]
},
{
"session": {
- "id": "debunking-myths-about-building-out-of-sea",
- "sourceId": "CDVQ7R",
- "title": "Debunking Myths about Building out of SEA",
- "description": "South East Asia is home to a burgeoning community of builders and some of the most influential projects in Ethereum. Listen in as SEA founders share their experiences and answer your questions about building out of this corner of the world.",
- "track": "Real World Ethereum",
- "type": "Panel",
- "expertise": "Beginner",
- "audience": "Local/SEA",
+ "id": "deca-12x",
+ "sourceId": "WYESYA",
+ "title": "Deca 12x",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Build",
- "Myth",
- "Local"
- ],
- "tags": [
- "Local Impact",
- "SEA",
- "myths",
- "SEA"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "matthew-tan",
- "harith-kamarul",
- "tn-lee",
- "loi-luu"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731646800000,
- "slot_end": 1731650400000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1SpHoMINj55MzEUWqqO7ToaiDbowMedsSM9tKnMWMaSY"
+ "slot_start": 1731474000000,
+ "slot_end": 1731475800000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1oXwhbXtA9_IkZiM1hj6x3YDfhq54XQGQeoHUbTHVK4I"
},
"vector": [
0,
@@ -198736,6 +198302,9 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
6,
0,
0,
@@ -198950,10 +198519,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
0,
0,
0,
@@ -199725,31 +199290,6 @@
0,
0,
0,
- 2,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -200045,6 +199585,31 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
2,
0,
0,
@@ -200058,32 +199623,43 @@
0,
0,
0,
- 0,
- 2,
0
]
},
{
"session": {
- "id": "deca-12x",
- "sourceId": "WYESYA",
- "title": "Deca 12x",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
+ "id": "decentralize-your-sequencer-a-guide-for-l2s",
+ "sourceId": "BNBCVC",
+ "title": "Decentralize your sequencer -- A guide for L2’s",
+ "description": "This talk will act as a river guide exploring the design space for L2 sequencer decentralization. It will cover:\r\n\r\n1. Should L2’s care about decentralizing a sequencer?\r\n2. What does it mean for UX?\r\n3. Forced Inclusion ≠ Decentralised sequencing\r\n4. ELI5 the approaches being taken by L2's\r\n5. Based rollups to the rescue?\r\n6. What are for optimistic / zk and / privacy rollups\r\n7. L2 Consensus networks are not the solution\r\n8. Decentralisation is not just about sequencing rights",
+ "track": "Layer 2",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Sequencer",
+ "Decentralisation"
+ ],
+ "tags": [
+ "Zk Rollups",
+ "Sufficient decentralization",
+ "Decentralization",
+ "sequencer",
+ "Decentralization",
+ "Sufficient decentralization",
+ "Zk Rollups"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "joe-andrews"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731474000000,
- "slot_end": 1731475800000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1oXwhbXtA9_IkZiM1hj6x3YDfhq54XQGQeoHUbTHVK4I"
+ "slot_start": 1731405600000,
+ "slot_end": 1731407400000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1faHlm1Vau0v1_f53rf67KFbBYY4FT3pugB04UolFn_M"
},
"vector": [
0,
@@ -200093,8 +199669,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -200312,6 +199886,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -200905,6 +200480,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -200937,6 +200513,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -200946,6 +200523,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -200990,13 +200568,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -201403,6 +200975,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -201421,38 +200994,46 @@
},
{
"session": {
- "id": "decentralize-your-sequencer-a-guide-for-l2s",
- "sourceId": "BNBCVC",
- "title": "Decentralize your sequencer -- A guide for L2’s",
- "description": "This talk will act as a river guide exploring the design space for L2 sequencer decentralization. It will cover:\r\n\r\n1. Should L2’s care about decentralizing a sequencer?\r\n2. What does it mean for UX?\r\n3. Forced Inclusion ≠ Decentralised sequencing\r\n4. ELI5 the approaches being taken by L2's\r\n5. Based rollups to the rescue?\r\n6. What are for optimistic / zk and / privacy rollups\r\n7. L2 Consensus networks are not the solution\r\n8. Decentralisation is not just about sequencing rights",
- "track": "Layer 2",
+ "id": "decentralized-outcome-funding-for-investigative-reporters",
+ "sourceId": "SJE7VP",
+ "title": "Decentralized Outcome Funding for Investigative Reporters",
+ "description": "Drawing upon the idea of impact certificates, this talk demonstrates how blockspace can be leveraged to solve double selling of impact (create change once and sell to many funders) and donating on brand rather than outcomes created. The session will go through a demo built by VoiceDeck in collaboration with the EF to help traditional newsrooms port their private database of impact as Hypercerts on Optimism, so they can receive funding based on recorded impact arising from their past stories.",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Sequencer",
- "Decentralisation"
- ],
"tags": [
- "Zk Rollups",
- "Sufficient decentralization",
- "Decentralization",
- "sequencer",
- "Decentralization",
- "Sufficient decentralization",
- "Zk Rollups"
+ "Effective Altruism",
+ "Ethereum for Good",
+ "Regenerative Applications",
+ "hypercerts",
+ "Effective Altruism",
+ "Ethereum for Good",
+ "Regenerative Applications"
],
- "language": "en",
- "speakers": [
- "joe-andrews"
+ "keywords": [
+ "Hypercerts"
],
+ "duration": 1332,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "7kS3Ealeyt8",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731405600000,
- "slot_end": 1731407400000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1faHlm1Vau0v1_f53rf67KFbBYY4FT3pugB04UolFn_M"
+ "slot_start": 1731465900000,
+ "slot_end": 1731467700000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Wcw6Mzk0DP95udiY_4VYK0pAVZ2Ac5fQgZmO7yWbJSg",
+ "resources_slides": null,
+ "speakers": [
+ "devansh-mehta"
+ ]
},
"vector": [
0,
@@ -201461,7 +201042,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -201679,9 +201259,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -202276,7 +201856,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -202309,7 +201888,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -202319,7 +201897,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -202334,10 +201911,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -202364,7 +201943,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -202452,6 +202030,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -202772,11 +202352,9 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
+ 2,
0,
0,
0,
@@ -202790,45 +202368,43 @@
},
{
"session": {
- "id": "decentralized-outcome-funding-for-investigative-reporters",
- "sourceId": "SJE7VP",
- "title": "Decentralized Outcome Funding for Investigative Reporters",
- "description": "Drawing upon the idea of impact certificates, this talk demonstrates how blockspace can be leveraged to solve double selling of impact (create change once and sell to many funders) and donating on brand rather than outcomes created. The session will go through a demo built by VoiceDeck in collaboration with the EF to help traditional newsrooms port their private database of impact as Hypercerts on Optimism, so they can receive funding based on recorded impact arising from their past stories.",
- "track": "Real World Ethereum",
+ "id": "decentralizing-access-to-ethereum-utilizing-ethereums-portal-networks",
+ "sourceId": "NWSNWX",
+ "title": "Decentralizing access to Ethereum utilizing Ethereum's Portal Networks",
+ "description": "Accessing Ethereum in a decentralized way has a high barrier to entry for reasons of cost (hardware), knowledge, or time. These problems cause users to rely on centralized providers.\r\n\r\nA few examples on how Ethereum's Portal Networks will tackle these centralizing forces\r\n- EIP 4444's + Portal History will allow nodes to maintain current day RPC, well saving 800GB of storage.\r\n- Portal State will allow wallets to use a decentralized backend instead of a centralized backend like Infura.",
+ "track": "Core Protocol",
"type": "Talk",
"expertise": "Beginner",
- "audience": "Product",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"tags": [
- "Effective Altruism",
- "Ethereum for Good",
- "Regenerative Applications",
- "hypercerts",
- "Effective Altruism",
- "Ethereum for Good",
- "Regenerative Applications"
+ "Decentralization",
+ "Decentralization",
+ "Light Clients"
],
"keywords": [
- "Hypercerts"
+ "EIP 4444s",
+ "Portal Network",
+ "Decentralization"
],
- "duration": 1332,
+ "duration": 1374,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "7kS3Ealeyt8",
+ "sources_swarmHash": "f14d2e446ae47d87640a810710fe55bf479671fca84990d0b042594273747c36",
+ "sources_youtubeId": "LZ_yWmm7ISg",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67342c889dbb7a90e1c174fe.vtt",
+ "transcript_text": " Hi, I'm Colby Miroslibil and I wanted to give a talk today on decentralized access to Ethereum, utilizing Ethereum portal networks, which might sound a little weird, but it will make sense through the talk. So the origins of Ethereum is it's like... Was creating a programmable blockchain or a world computer. Instead of just having a simple ledger or colored coins, which were basically like coins with random features, you could program many features. And Ethereum's emphasis on this was decentralization and censorship resistance. But how did people access Ethereum? This was done through full nodes, which provided you a gateway to the Ethereum protocol through the JSON RPC. Full nodes were often long-running processes, because if you turn off your laptop and turn it on, you have to re-sync, which is kind of hard if you want to send a transaction. You have to wait a few hours. So full nodes weren't always unaccessible. At the start, you could spin up a node very fast. But then as requirements grew over time, it became harder. I would say one of the greatest inaccessibilities to Ethereum is knowledge. Being able to run a node is a feat which all of us in the room can do, but can your grandma do it? And for Ethereum to be accessible, you need it to be like you don't want to run this thing, but you need to know something. Time, you need to sync a node. As I was saying, like, if you turn on a laptop, like, on and off, syncing a node to send a transaction is very unreasonable, and the IT costs associated with that. Updating your node for hard forks is kind of annoying when it's, like, repetitive every year. And then the biggest one, I guess, is hardware costs. It's projected in the next four months by eStakers that validators will need to update to four terabyte disks. And my little picture of like the man holding the world, which is like a geth node, it's like pretty sizable and really annoying that you need to buy a SSD just to use Ethereum. So because Ethereum was unaccessible, this created WAVE for centralized providers, which took down the barrier of entry to access Ethereum, but it came with this consequence of centralization, which earlier when I said the origin, it's something we didn't want. So with one of the main concerns being the storage requirements, there is this nifty thing called EAP-4-4s or history expiry, where in the purge path, this is basically what if instead of all nodes storing all the data, we lowered the costs by not requiring them to store old data, what's no longer readily needed to run a validator? This doesn't mean nodes can't store the history, but it means they're not responsible for it all. But how do we achieve EAP-4-4s? And enter the portal network. What is portal? Instead of depending on phone loads which hold all, like the whole pie of data, what if it could only hold a slice of that data? Portal distributes this responsibility amongst numerous small nodes that are independent of each other. So you could think of it as like a slice of a pie, but the whole pie is still accessible through Portal. Portal is also sustainable. It's both a server and a client, which is very important because this problem has been here for a very long time. Previously in the past, there's been attempts at this. For example, LES, which the concept of it was an altruistic full node would host the server to a bunch of light nodes. But the problem that occurred was there was a bunch of users who wanted to run a light node, but not enough people who wanted to run a full node, so they were all overloaded. Portal switches this up by making all the participants contribute back to it, so it's sustainable into the future. We also get the benefits before as having lower storage requirements and lighter CPU usage. But how does this work? Portal uses a fundamentally different peer-to-peer model than Ethereum today. Through distributed hash tables. Distributed hash tables enables decentralized storage and lookup system, where each piece of content is addressed by a unique identifier and stored in multiple nodes for redundancy. DHTs make it possible to be able to look up the data even if you don't sort it yourself, which is what I was going by when I said you could sort a piece of the pie but still have access to the whole thing. And as I was saying, a totally different peer-to-peer model, Portal is also a replacement for the legacy dev peer-to-peer network. In that, imagine dev P2P is this triangle where you have to participate in everything to access anything. Portal breaks this up into different networks. One of our first ones we'll be launching is Portal History. And then there's others. But what does each network do? Portal history contains headers, bodies, and receipts. Portal state allows you to access the state, such as your balances and contract storage. Portal index is if you want to find which block body your transaction's in, and the portal transaction mempool will be very interesting with vertical and stateless clients. Currently, there's no hard solution for how we'll handle sending transactions in a stateless world, and we believe that portal is in a unique position to solve this problem. And we will solve this problem. But anyways, with having access to all that data, you also gain access to a full archival node but, like, distributed trademark. And the cool thing about that is it's, like, you can basically run a portal node and have instant access, which is massive, because in the past, if you wanted to have full archival access, which was provable, you would need to run a geth node. But to run a geth archival node, that requires 20 terabytes of storage, which is massive, and it also takes over a month to sync, which if you just want quick access to archival Ethereum data, that sucks, especially if you're a researcher and you just want to research stuff instead of waiting a month to start your research. So portal is fully provable, which is huge. There's kind of two paths to do this. So you could use our portal beacon network, which will be very useful for wallet use cases, where you could basically put portal directly in place of a centralized provider. Portal beacon network is an implementation of the consensus layer likeline protocol, and it will be integrated in any implementation. So if you want to use portal, you don't need to think of anything else. You just integrate our libraries libraries and it's proven. A big use case, though, as I said before, will also be for full nodes. And for that, they're already running an Ethereum consensus layer client, which they can just repurpose to prove this data. So as I was saying before, there's all these portal networks. But is there a dependency to prove? And there is. So, for state, if you wanted to get your balance, you would get a proof to the state route, which would be in a header, but how do you know the header is real? There's accumulators in the beacon network, like consensus client, called historical summaries, which is in the beacon state. So depending on your use case, if you only needed historical data, well, then you would basically have this two-node dependency, but if you needed state, you would have an additional one. And by doing this, you only need to run a portal network of what your requirements are for the use case. How do portal clients initially get the data? Currently, it's through bridges. Bridges are basically full nodes which have access to all the data. But as portal gets adopted in execution layer clients, which I probably can't talk about it, but like an announcement on the way. But anyways, so execution layer clients already gossip blocks around the network. Portal is kind of the same in that execution layer clients will be able to gossip blocks around the network, but they'll only need to gossip to a select few peers. Where if they have 50 peers, now that nodes only store a slice, they'd only be required to gossip this data to maybe 10 or 5%, which saves bandwidth. Incentives. So why would people want to run a portal node? Well, financial incentives are hard. It leads to a race to the bottom, and it's very easy to game. In that, let's say I want to maximize my income from running a portal node, well, then I could offer the worst service, but also allow for the most whatever metric you use to reward people. There are other projects trying to achieve this approach, and wouldn't it be really cool if everybody could participate in Ethereum's protocol for free? Because I don't want to pay someone to send a transaction or pay someone to get my balance when I open my wallet. We believe that Ethereum's protocol has innate value. That innate value is being able to send money, fetch your balance, use L2s. And Portal gives you access to this on cheap hardware. So if the value of Ethereum is high enough and the cost of running a portal node is so minimally small, we think the incentives are aligned for people to run these nodes. Use cases, as I said earlier, lighter full nodes with storage requirements increasing. Being able to add 4.4s while maintaining current day UX. UX by if you just implemented 4.4s, your node would have no idea of what the past history was. With 4.4s, your execution client, it would be like you could fully respond to any request, and it would be like nothing ever happened. Another thing is nearly instant sync times for full archival node access. And the other is a replacement for centralized providers in use cases such as mobile wallets, which is pretty cool. But what's the catch, you may be asking? I'm selling this solution that seems too good to be true. So the trade-off is between latency and storage. Nothing is as fast as having it on disk, but for most of the data, you don't actually need to access it that often. So we believe that the trade-off for a majority of use cases is correct, is actually there. And the only time you really need quick access is if you're block building. And for mobile wallets, if it's fast enough, it's good enough. So for the first time, you can choose how you participate in Ethereum's protocol. I think this is kind of analogous to the infinite garden analogy that is often told on Ethereum's future. Instead of basically running a full node and requiring everything, there's tons of possibilities how Portal can change how you access Ethereum's protocol. Whether it's only subscribing to a few parts of the protocol, only history, or accessing the full protocol, it's finally a choice instead of a requirement to handle it all, which is, yeah, really annoying. Who's building portal clients? Well, the Ethereum Foundation has been at the centre of this from the start, but from the start we have also been assisted by Status and Ethereum JS, which has been massive. Recently, Nethermind has been taking the stage. And for execution layer clients, they have been working the hardest on this from pretty recently, like last year, which is really cool. There's open source teams from around the world who are building clients. Another client's being built by EPF members. And I guess you guys could build Portal clients as well. We have clients being built in all these languages, so if you want to use Portal, you can. I'm sure everybody would be happy to answer questions, and I think we covered the whole stack, which is cool. Portal history is ready for developers to start using, and we have the data to back that up. So we built a statistics platform for seeing if our stuff works, and we call that GLaDOS. For the past few months, we had zero failed audits on our network, and what that means is the data is available on the network. And there hasn't been any case where we couldn't find it. So the system has been robust for months. And that's really exciting. There's a QR code there, but you should be able to find it on our website as well. Another exciting use case I was talking about earlier is wallets. We're building Trin Desktop, which is hoping to target everything but the browser. So hopefully, like, Ethereum.js does that for us. Here's the front screen. You turn it on, and it's like, woo, stats. But you can also do eth get block by number, get block by hash, get balance. But in the next few months, we're hoping to integrate a wallet as we want to be like the test bed to show people this actually works. And what better way to do that than do it yourself and show people? And it's also, as I was saying earlier, you can configure your storage requirements. So if you set two gigabytes, you'll only ever need to contribute two gigabytes. You won't need to buy a disk in a year, which is really cool because it sucks to buy a four terabyte disk when you already bought a two terabyte one. So now anybody can participate in Ethereum's protocol. As I was saying earlier, you could just integrate that into a wallet and the user doesn't have to know it's running, which is really cool. And where to find out more? We have a QR code for our Discord invite, which is really useful if you want to ask questions. We have our website with guides and blog posts and how to set up most of the clients already. We have a Twitter, which our team hates Twitter, but it's good for getting people to know stuff. And then we have specs, so if you wanna contribute, every team is super open to it, and they'd be super happy. We need to improve our issues a little bit, but that can be fixed. And yeah. So thank you for coming to, I guess, this talk on Portal. And yeah, thank you. Okay, so let's go through some questions. I'm going to read them for you. Can I use Portal Network today to check my balance? If not, when? Same question for doing an ETH transfer. So you can check your balance if it's within the first million blocks. So if you guys used Ethereum nine years ago, you can check your balance today. We expect balance for latest account, for checking balance for the head to be available in Q1 or Q2. We just need to finish some infrastructure to support that. What is the biggest hurdle to getting all clients to adopt the portal network, and how can the community help portal get adopted? I would say the biggest thing has been awareness. Two years ago, people were like, what portal? And then it's like a minimal implementation. And all these questions, what never really made sense. But especially this year, people actually know what portal is, and it's really cool to see people referencing portal, like actually about it, and we don't have to do all the talking ourselves. So I think just talking to people about it is awesome. Awesome. What is the minimum percentage of network data that a portal network is expected to have? So we have thrown numbers like 100 megabytes, but that's fully configurable. Since the requirements are so low, for our client at least, we wouldn't be surprised if we set it to one gigabyte because realistically someone wouldn't notice. Most apps are 500 megabytes on their phone. So it's like if we use a gigabyte, they probably wouldn't notice. Like most apps are 500 megabytes on their phone. So it's like if we use like a gigabyte, like they probably wouldn't notice, but it's configurable. And I think the next two questions can be combined. How does portal network compared to classic peer-to-peer file sharing networks such as BitTorrent? So one of the problems with BitTorrent is it doesn't have an inherent way to prove the data or validate it. So you run into problems of you need to download this huge section of data and it's very uninformed. Portal is different in that all the data you can fetch from the network is provable, so it's much easier for a client to, let's say, fetch any piece of data they want, where through torrent, they would probably have to index this data and do some kind of, like, out-of-band proof, which would be a lot more complex and have a much worse UX experience. And you answered this one in your presentation, but it was asked before. So is there incentive model for running a portal network node? For writing a portal network node, I guess if you wanted to use it in your wallet and you used a language that wasn't there yet, I guess that would be the incentive. Like accessing Ethereum with instant sync times. Decentralized. Very cool. Could one implement an archive node using portal as a back end? Yes. So the idea is like portal would have all the data that an archival node would have. So you could just use portal as your archival node. It would be a little slow. But you could. What are the expected hardware and network specs in gigabits for running portal nodes, and who do you think will be ready to operate these altruistically? I think that the top three execution layer clients would be running all these by default, so that's a lot. Other than that, if you're running a wallet on your phone, I guess that's like an ultra, that's not really altruistic. You have actual utility in that. So I think we can do quite fine with, well, ignoring altruistic use cases. Has there been engagement with IPFS community? It sounds like there's a lot of overlap with DHTs, accessing content, address data, etc. So some of the issues with IPFS is since they have no validity scheme, one of the things is data is constantly cycled off the network. And because of our strong validation conditions, it basically means if we have enough storage, it's on the network and it won't be flushed off, which is really important for the longevity and robustness of portal, which isn't there with IPFS. Also, they use TCP, which has much higher latency. I forgot to mention our talk, but we're based off disk v5, which is the current day node discovery protocol for Ethereum. And it uses UDP, which is much quicker for getting responses back. Especially if you have to ping multiple peers, that adds up. Don't some nodes need to sacrifice in portal network for this to work? Not lots will run archival data, but lots may query it and these might get spammed. So a portal node would only need to hold a very small slice of the data. So if a full node is only storing one gigabyte per portal, they probably wouldn't really notice it. There is no real requirement that they store all the archive on their node. The idea is that all the full nodes on Ethereum store way less. And it's like they all contribute, where currently it's like every node has to store all the data. What if we did this a little more smart, I guess? What are the guarantees that the data will not be lost over time? I think the guarantees is kind of analogous to what I said earlier about validation. Any storage we have above the minimal requirement is used for redundancy. But if worst case scenario, there's other archival solutions, Portal is really good for accessing the data, but in a worst case scenario, you can use archival formats such as ERA or ERA1. So the data wouldn't be lost if it wasn't on Portal. There's optimized formats for archival. Portal is really good if you want to access it. What is the most resource constrained device that has been a peer on portal? For us, it's basically been, I guess, Raspberry Pis. I know Raspberry Pis have gone a little strong, but I don't, like, when we run it, we don't even use a core, and we use, like, 300 megabytes of RAM, so, like, something with maybe, like, 500 megabytes of RAM would be fine to run Portal on, and we haven't even optimized it yet. Does Portal support WebSocket connections? Through the RPC? That would be dependent on the implementation. Ours does, but it's, I guess, the implementation's choice. Cool. Can we get another round of applause for Colby? Thank you so much.",
"eventId": "devcon-7",
- "slot_start": 1731465900000,
- "slot_end": 1731467700000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1Wcw6Mzk0DP95udiY_4VYK0pAVZ2Ac5fQgZmO7yWbJSg",
+ "slot_start": 1731470400000,
+ "slot_end": 1731472200000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1B7KXH5uVHB04jWwnsYtQMYYbRlXaYPjx6HTM5n2vYhk",
"resources_slides": null,
"speakers": [
- "devansh-mehta"
+ "kolby-moroz-liebl"
]
},
"vector": [
@@ -202836,9 +202412,10 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
- 6,
0,
0,
0,
@@ -203600,6 +203177,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -203681,6 +203259,54 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -203710,12 +203336,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -203830,57 +203454,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -204149,11 +203722,11 @@
0,
2,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -204167,56 +203740,40 @@
},
{
"session": {
- "id": "decentralizing-access-to-ethereum-utilizing-ethereums-portal-networks",
- "sourceId": "NWSNWX",
- "title": "Decentralizing access to Ethereum utilizing Ethereum's Portal Networks",
- "description": "Accessing Ethereum in a decentralized way has a high barrier to entry for reasons of cost (hardware), knowledge, or time. These problems cause users to rely on centralized providers.\r\n\r\nA few examples on how Ethereum's Portal Networks will tackle these centralizing forces\r\n- EIP 4444's + Portal History will allow nodes to maintain current day RPC, well saving 800GB of storage.\r\n- Portal State will allow wallets to use a decentralized backend instead of a centralized backend like Infura.",
- "track": "Core Protocol",
+ "id": "decentralizing-consensys-to-catalyze-a-network-state-in-the-emerging-decentralized-web3-ai-global-economy",
+ "sourceId": "STX9DW",
+ "title": "Decentralizing Consensys to Catalyze a Network State in the Emerging Decentralized Web3 + AI Global Economy",
+ "description": "Supported by MetaMask & Linea infrastructure, this open network state will be one of many interoperating token economies. This talk will briefly trace the arc from web1 to web3. Two technologies are maturing that will together serve as the foundation of web3 – a user-owned and controlled information technology infrastructure for the planet. They are AI and decentralized protocols. This complementary tandem must evolve together in order for humanity to evolve beyond the current adolescent state",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Beginner",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
+ "keywords": [],
"tags": [
"Decentralization",
- "Decentralization",
- "Light Clients"
- ],
- "keywords": [
- "EIP 4444s",
- "Portal Network",
- "Decentralization"
+ "Ethereum for Good",
+ "Network State"
],
- "duration": 1374,
"language": "en",
- "sources_swarmHash": "f14d2e446ae47d87640a810710fe55bf479671fca84990d0b042594273747c36",
- "sources_youtubeId": "LZ_yWmm7ISg",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67342c889dbb7a90e1c174fe.vtt",
- "transcript_text": " Hi, I'm Colby Miroslibil and I wanted to give a talk today on decentralized access to Ethereum, utilizing Ethereum portal networks, which might sound a little weird, but it will make sense through the talk. So the origins of Ethereum is it's like... Was creating a programmable blockchain or a world computer. Instead of just having a simple ledger or colored coins, which were basically like coins with random features, you could program many features. And Ethereum's emphasis on this was decentralization and censorship resistance. But how did people access Ethereum? This was done through full nodes, which provided you a gateway to the Ethereum protocol through the JSON RPC. Full nodes were often long-running processes, because if you turn off your laptop and turn it on, you have to re-sync, which is kind of hard if you want to send a transaction. You have to wait a few hours. So full nodes weren't always unaccessible. At the start, you could spin up a node very fast. But then as requirements grew over time, it became harder. I would say one of the greatest inaccessibilities to Ethereum is knowledge. Being able to run a node is a feat which all of us in the room can do, but can your grandma do it? And for Ethereum to be accessible, you need it to be like you don't want to run this thing, but you need to know something. Time, you need to sync a node. As I was saying, like, if you turn on a laptop, like, on and off, syncing a node to send a transaction is very unreasonable, and the IT costs associated with that. Updating your node for hard forks is kind of annoying when it's, like, repetitive every year. And then the biggest one, I guess, is hardware costs. It's projected in the next four months by eStakers that validators will need to update to four terabyte disks. And my little picture of like the man holding the world, which is like a geth node, it's like pretty sizable and really annoying that you need to buy a SSD just to use Ethereum. So because Ethereum was unaccessible, this created WAVE for centralized providers, which took down the barrier of entry to access Ethereum, but it came with this consequence of centralization, which earlier when I said the origin, it's something we didn't want. So with one of the main concerns being the storage requirements, there is this nifty thing called EAP-4-4s or history expiry, where in the purge path, this is basically what if instead of all nodes storing all the data, we lowered the costs by not requiring them to store old data, what's no longer readily needed to run a validator? This doesn't mean nodes can't store the history, but it means they're not responsible for it all. But how do we achieve EAP-4-4s? And enter the portal network. What is portal? Instead of depending on phone loads which hold all, like the whole pie of data, what if it could only hold a slice of that data? Portal distributes this responsibility amongst numerous small nodes that are independent of each other. So you could think of it as like a slice of a pie, but the whole pie is still accessible through Portal. Portal is also sustainable. It's both a server and a client, which is very important because this problem has been here for a very long time. Previously in the past, there's been attempts at this. For example, LES, which the concept of it was an altruistic full node would host the server to a bunch of light nodes. But the problem that occurred was there was a bunch of users who wanted to run a light node, but not enough people who wanted to run a full node, so they were all overloaded. Portal switches this up by making all the participants contribute back to it, so it's sustainable into the future. We also get the benefits before as having lower storage requirements and lighter CPU usage. But how does this work? Portal uses a fundamentally different peer-to-peer model than Ethereum today. Through distributed hash tables. Distributed hash tables enables decentralized storage and lookup system, where each piece of content is addressed by a unique identifier and stored in multiple nodes for redundancy. DHTs make it possible to be able to look up the data even if you don't sort it yourself, which is what I was going by when I said you could sort a piece of the pie but still have access to the whole thing. And as I was saying, a totally different peer-to-peer model, Portal is also a replacement for the legacy dev peer-to-peer network. In that, imagine dev P2P is this triangle where you have to participate in everything to access anything. Portal breaks this up into different networks. One of our first ones we'll be launching is Portal History. And then there's others. But what does each network do? Portal history contains headers, bodies, and receipts. Portal state allows you to access the state, such as your balances and contract storage. Portal index is if you want to find which block body your transaction's in, and the portal transaction mempool will be very interesting with vertical and stateless clients. Currently, there's no hard solution for how we'll handle sending transactions in a stateless world, and we believe that portal is in a unique position to solve this problem. And we will solve this problem. But anyways, with having access to all that data, you also gain access to a full archival node but, like, distributed trademark. And the cool thing about that is it's, like, you can basically run a portal node and have instant access, which is massive, because in the past, if you wanted to have full archival access, which was provable, you would need to run a geth node. But to run a geth archival node, that requires 20 terabytes of storage, which is massive, and it also takes over a month to sync, which if you just want quick access to archival Ethereum data, that sucks, especially if you're a researcher and you just want to research stuff instead of waiting a month to start your research. So portal is fully provable, which is huge. There's kind of two paths to do this. So you could use our portal beacon network, which will be very useful for wallet use cases, where you could basically put portal directly in place of a centralized provider. Portal beacon network is an implementation of the consensus layer likeline protocol, and it will be integrated in any implementation. So if you want to use portal, you don't need to think of anything else. You just integrate our libraries libraries and it's proven. A big use case, though, as I said before, will also be for full nodes. And for that, they're already running an Ethereum consensus layer client, which they can just repurpose to prove this data. So as I was saying before, there's all these portal networks. But is there a dependency to prove? And there is. So, for state, if you wanted to get your balance, you would get a proof to the state route, which would be in a header, but how do you know the header is real? There's accumulators in the beacon network, like consensus client, called historical summaries, which is in the beacon state. So depending on your use case, if you only needed historical data, well, then you would basically have this two-node dependency, but if you needed state, you would have an additional one. And by doing this, you only need to run a portal network of what your requirements are for the use case. How do portal clients initially get the data? Currently, it's through bridges. Bridges are basically full nodes which have access to all the data. But as portal gets adopted in execution layer clients, which I probably can't talk about it, but like an announcement on the way. But anyways, so execution layer clients already gossip blocks around the network. Portal is kind of the same in that execution layer clients will be able to gossip blocks around the network, but they'll only need to gossip to a select few peers. Where if they have 50 peers, now that nodes only store a slice, they'd only be required to gossip this data to maybe 10 or 5%, which saves bandwidth. Incentives. So why would people want to run a portal node? Well, financial incentives are hard. It leads to a race to the bottom, and it's very easy to game. In that, let's say I want to maximize my income from running a portal node, well, then I could offer the worst service, but also allow for the most whatever metric you use to reward people. There are other projects trying to achieve this approach, and wouldn't it be really cool if everybody could participate in Ethereum's protocol for free? Because I don't want to pay someone to send a transaction or pay someone to get my balance when I open my wallet. We believe that Ethereum's protocol has innate value. That innate value is being able to send money, fetch your balance, use L2s. And Portal gives you access to this on cheap hardware. So if the value of Ethereum is high enough and the cost of running a portal node is so minimally small, we think the incentives are aligned for people to run these nodes. Use cases, as I said earlier, lighter full nodes with storage requirements increasing. Being able to add 4.4s while maintaining current day UX. UX by if you just implemented 4.4s, your node would have no idea of what the past history was. With 4.4s, your execution client, it would be like you could fully respond to any request, and it would be like nothing ever happened. Another thing is nearly instant sync times for full archival node access. And the other is a replacement for centralized providers in use cases such as mobile wallets, which is pretty cool. But what's the catch, you may be asking? I'm selling this solution that seems too good to be true. So the trade-off is between latency and storage. Nothing is as fast as having it on disk, but for most of the data, you don't actually need to access it that often. So we believe that the trade-off for a majority of use cases is correct, is actually there. And the only time you really need quick access is if you're block building. And for mobile wallets, if it's fast enough, it's good enough. So for the first time, you can choose how you participate in Ethereum's protocol. I think this is kind of analogous to the infinite garden analogy that is often told on Ethereum's future. Instead of basically running a full node and requiring everything, there's tons of possibilities how Portal can change how you access Ethereum's protocol. Whether it's only subscribing to a few parts of the protocol, only history, or accessing the full protocol, it's finally a choice instead of a requirement to handle it all, which is, yeah, really annoying. Who's building portal clients? Well, the Ethereum Foundation has been at the centre of this from the start, but from the start we have also been assisted by Status and Ethereum JS, which has been massive. Recently, Nethermind has been taking the stage. And for execution layer clients, they have been working the hardest on this from pretty recently, like last year, which is really cool. There's open source teams from around the world who are building clients. Another client's being built by EPF members. And I guess you guys could build Portal clients as well. We have clients being built in all these languages, so if you want to use Portal, you can. I'm sure everybody would be happy to answer questions, and I think we covered the whole stack, which is cool. Portal history is ready for developers to start using, and we have the data to back that up. So we built a statistics platform for seeing if our stuff works, and we call that GLaDOS. For the past few months, we had zero failed audits on our network, and what that means is the data is available on the network. And there hasn't been any case where we couldn't find it. So the system has been robust for months. And that's really exciting. There's a QR code there, but you should be able to find it on our website as well. Another exciting use case I was talking about earlier is wallets. We're building Trin Desktop, which is hoping to target everything but the browser. So hopefully, like, Ethereum.js does that for us. Here's the front screen. You turn it on, and it's like, woo, stats. But you can also do eth get block by number, get block by hash, get balance. But in the next few months, we're hoping to integrate a wallet as we want to be like the test bed to show people this actually works. And what better way to do that than do it yourself and show people? And it's also, as I was saying earlier, you can configure your storage requirements. So if you set two gigabytes, you'll only ever need to contribute two gigabytes. You won't need to buy a disk in a year, which is really cool because it sucks to buy a four terabyte disk when you already bought a two terabyte one. So now anybody can participate in Ethereum's protocol. As I was saying earlier, you could just integrate that into a wallet and the user doesn't have to know it's running, which is really cool. And where to find out more? We have a QR code for our Discord invite, which is really useful if you want to ask questions. We have our website with guides and blog posts and how to set up most of the clients already. We have a Twitter, which our team hates Twitter, but it's good for getting people to know stuff. And then we have specs, so if you wanna contribute, every team is super open to it, and they'd be super happy. We need to improve our issues a little bit, but that can be fixed. And yeah. So thank you for coming to, I guess, this talk on Portal. And yeah, thank you. Okay, so let's go through some questions. I'm going to read them for you. Can I use Portal Network today to check my balance? If not, when? Same question for doing an ETH transfer. So you can check your balance if it's within the first million blocks. So if you guys used Ethereum nine years ago, you can check your balance today. We expect balance for latest account, for checking balance for the head to be available in Q1 or Q2. We just need to finish some infrastructure to support that. What is the biggest hurdle to getting all clients to adopt the portal network, and how can the community help portal get adopted? I would say the biggest thing has been awareness. Two years ago, people were like, what portal? And then it's like a minimal implementation. And all these questions, what never really made sense. But especially this year, people actually know what portal is, and it's really cool to see people referencing portal, like actually about it, and we don't have to do all the talking ourselves. So I think just talking to people about it is awesome. Awesome. What is the minimum percentage of network data that a portal network is expected to have? So we have thrown numbers like 100 megabytes, but that's fully configurable. Since the requirements are so low, for our client at least, we wouldn't be surprised if we set it to one gigabyte because realistically someone wouldn't notice. Most apps are 500 megabytes on their phone. So it's like if we use a gigabyte, they probably wouldn't notice. Like most apps are 500 megabytes on their phone. So it's like if we use like a gigabyte, like they probably wouldn't notice, but it's configurable. And I think the next two questions can be combined. How does portal network compared to classic peer-to-peer file sharing networks such as BitTorrent? So one of the problems with BitTorrent is it doesn't have an inherent way to prove the data or validate it. So you run into problems of you need to download this huge section of data and it's very uninformed. Portal is different in that all the data you can fetch from the network is provable, so it's much easier for a client to, let's say, fetch any piece of data they want, where through torrent, they would probably have to index this data and do some kind of, like, out-of-band proof, which would be a lot more complex and have a much worse UX experience. And you answered this one in your presentation, but it was asked before. So is there incentive model for running a portal network node? For writing a portal network node, I guess if you wanted to use it in your wallet and you used a language that wasn't there yet, I guess that would be the incentive. Like accessing Ethereum with instant sync times. Decentralized. Very cool. Could one implement an archive node using portal as a back end? Yes. So the idea is like portal would have all the data that an archival node would have. So you could just use portal as your archival node. It would be a little slow. But you could. What are the expected hardware and network specs in gigabits for running portal nodes, and who do you think will be ready to operate these altruistically? I think that the top three execution layer clients would be running all these by default, so that's a lot. Other than that, if you're running a wallet on your phone, I guess that's like an ultra, that's not really altruistic. You have actual utility in that. So I think we can do quite fine with, well, ignoring altruistic use cases. Has there been engagement with IPFS community? It sounds like there's a lot of overlap with DHTs, accessing content, address data, etc. So some of the issues with IPFS is since they have no validity scheme, one of the things is data is constantly cycled off the network. And because of our strong validation conditions, it basically means if we have enough storage, it's on the network and it won't be flushed off, which is really important for the longevity and robustness of portal, which isn't there with IPFS. Also, they use TCP, which has much higher latency. I forgot to mention our talk, but we're based off disk v5, which is the current day node discovery protocol for Ethereum. And it uses UDP, which is much quicker for getting responses back. Especially if you have to ping multiple peers, that adds up. Don't some nodes need to sacrifice in portal network for this to work? Not lots will run archival data, but lots may query it and these might get spammed. So a portal node would only need to hold a very small slice of the data. So if a full node is only storing one gigabyte per portal, they probably wouldn't really notice it. There is no real requirement that they store all the archive on their node. The idea is that all the full nodes on Ethereum store way less. And it's like they all contribute, where currently it's like every node has to store all the data. What if we did this a little more smart, I guess? What are the guarantees that the data will not be lost over time? I think the guarantees is kind of analogous to what I said earlier about validation. Any storage we have above the minimal requirement is used for redundancy. But if worst case scenario, there's other archival solutions, Portal is really good for accessing the data, but in a worst case scenario, you can use archival formats such as ERA or ERA1. So the data wouldn't be lost if it wasn't on Portal. There's optimized formats for archival. Portal is really good if you want to access it. What is the most resource constrained device that has been a peer on portal? For us, it's basically been, I guess, Raspberry Pis. I know Raspberry Pis have gone a little strong, but I don't, like, when we run it, we don't even use a core, and we use, like, 300 megabytes of RAM, so, like, something with maybe, like, 500 megabytes of RAM would be fine to run Portal on, and we haven't even optimized it yet. Does Portal support WebSocket connections? Through the RPC? That would be dependent on the implementation. Ours does, but it's, I guess, the implementation's choice. Cool. Can we get another round of applause for Colby? Thank you so much.",
- "eventId": "devcon-7",
- "slot_start": 1731470400000,
- "slot_end": 1731472200000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1B7KXH5uVHB04jWwnsYtQMYYbRlXaYPjx6HTM5n2vYhk",
- "resources_slides": null,
"speakers": [
- "kolby-moroz-liebl"
- ]
+ "joe-lubin"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731580200000,
+ "slot_end": 1731582000000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/11eX1oRXoI4urF046XwUWj6LWwTjgZKotWz4aBKhGwB4"
},
"vector": [
0,
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -204433,11 +203990,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -204979,7 +204536,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -205007,6 +204563,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -205085,6 +204642,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -205519,13 +205077,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
2,
0,
- 2,
- 0,
0,
0,
0,
@@ -205542,31 +205099,40 @@
},
{
"session": {
- "id": "decentralizing-consensys-to-catalyze-a-network-state-in-the-emerging-decentralized-web3-ai-global-economy",
- "sourceId": "STX9DW",
- "title": "Decentralizing Consensys to Catalyze a Network State in the Emerging Decentralized Web3 + AI Global Economy",
- "description": "Supported by MetaMask & Linea infrastructure, this open network state will be one of many interoperating token economies. This talk will briefly trace the arc from web1 to web3. Two technologies are maturing that will together serve as the foundation of web3 – a user-owned and controlled information technology infrastructure for the planet. They are AI and decentralized protocols. This complementary tandem must evolve together in order for humanity to evolve beyond the current adolescent state",
+ "id": "decentralizing-economic-opportunity-communities-using-crypto-and-decentralized-protocols-to-make-local-economic-impact-in-brazil-nigeria-and-kenya",
+ "sourceId": "SRYTXY",
+ "title": "Decentralizing economic opportunity: Communities using crypto & decentralized protocols to make local economic impact in Brazil, Nigeria & Kenya",
+ "description": "In communities facing economic scarcity, decentralized currencies are seen as a transformative solution. But what is their real-world impact? This talk explores the stories of three communities using crypto to drive local economic opportunities. It examines what brought them to crypto, the pros and cons of adopting tokens and focuses on diverse use cases like UBI, credit, and community currencies. Features video, data, and impact metrics of the people on the ground in underserved economies.",
"track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [],
+ "keywords": [
+ "ReFi",
+ "Emerging Markets"
+ ],
"tags": [
- "Decentralization",
+ "Use Cases",
"Ethereum for Good",
- "Network State"
+ "Local Impact",
+ "market",
+ "emerging",
+ "Ethereum for Good",
+ "Local Impact",
+ "Use Cases"
],
"language": "en",
"speakers": [
- "joe-lubin"
+ "anna-stone",
+ "damaris-njoroge"
],
"eventId": "devcon-7",
- "slot_start": 1731580200000,
- "slot_end": 1731582000000,
+ "slot_start": 1731409200000,
+ "slot_end": 1731411000000,
"slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/11eX1oRXoI4urF046XwUWj6LWwTjgZKotWz4aBKhGwB4"
+ "resources_presentation": "https://docs.google.com/presentation/d/1_dONrIsV4L0B5mPO_9XqzEKOZKIP8ACpAPTEAQfEWMQ"
},
"vector": [
0,
@@ -205796,12 +205362,9 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -206357,6 +205920,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -206368,7 +205932,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -206400,6 +205963,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -206423,7 +205987,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -206563,10 +206126,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -206886,12 +206451,10 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -206904,40 +206467,39 @@
},
{
"session": {
- "id": "decentralizing-economic-opportunity-communities-using-crypto-and-decentralized-protocols-to-make-local-economic-impact-in-brazil-nigeria-and-kenya",
- "sourceId": "SRYTXY",
- "title": "Decentralizing economic opportunity: Communities using crypto & decentralized protocols to make local economic impact in Brazil, Nigeria & Kenya",
- "description": "In communities facing economic scarcity, decentralized currencies are seen as a transformative solution. But what is their real-world impact? This talk explores the stories of three communities using crypto to drive local economic opportunities. It examines what brought them to crypto, the pros and cons of adopting tokens and focuses on diverse use cases like UBI, credit, and community currencies. Features video, data, and impact metrics of the people on the ground in underserved economies.",
+ "id": "decentralizing-the-internets-collaboration-layer",
+ "sourceId": "NZMSMG",
+ "title": "Decentralizing the Internet's collaboration layer",
+ "description": "Over half of the world’s Internet users trust one closed-source, centralized app suite for their daily knowledge creation and collaboration: Google Workspace.\r\n\r\nAs a core part of what people use the Internet for, it should offer similar robustness as the Internet does through sufficient decentralization. The decentralized stack required for such apps is now possible. The talk explore this stack and introduces examples of dapps we built with it incl. this year's Devcon's collaboration stack.",
"track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Beginner",
+ "expertise": "Intermediate",
"audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "ReFi",
- "Emerging Markets"
+ "mutual",
+ "aid"
],
"tags": [
+ "Coordination",
+ "Privacy",
"Use Cases",
- "Ethereum for Good",
- "Local Impact",
- "market",
- "emerging",
- "Ethereum for Good",
- "Local Impact",
+ "mutual",
+ "aid",
+ "Coordination",
+ "Privacy",
"Use Cases"
],
"language": "en",
"speakers": [
- "anna-stone",
- "damaris-njoroge"
+ "andreas-tsamados"
],
"eventId": "devcon-7",
- "slot_start": 1731409200000,
- "slot_end": 1731411000000,
+ "slot_start": 1731555000000,
+ "slot_end": 1731556200000,
"slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1_dONrIsV4L0B5mPO_9XqzEKOZKIP8ACpAPTEAQfEWMQ"
+ "resources_presentation": "https://docs.google.com/presentation/d/1XQpLsYFcvAaRsWM6b13TUaTHGrXpSSKJ4fVPEoKkJfw"
},
"vector": [
0,
@@ -207168,7 +206730,8 @@
0,
0,
0,
- 6,
+ 0,
+ 0,
6,
0,
0,
@@ -207728,7 +207291,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -207768,10 +207330,31 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -207784,6 +207367,11 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -207886,62 +207474,33 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 2,
0,
0,
0,
@@ -208253,9 +207812,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -208275,39 +207834,39 @@
},
{
"session": {
- "id": "decentralizing-the-internets-collaboration-layer",
- "sourceId": "NZMSMG",
- "title": "Decentralizing the Internet's collaboration layer",
- "description": "Over half of the world’s Internet users trust one closed-source, centralized app suite for their daily knowledge creation and collaboration: Google Workspace.\r\n\r\nAs a core part of what people use the Internet for, it should offer similar robustness as the Internet does through sufficient decentralization. The decentralized stack required for such apps is now possible. The talk explore this stack and introduces examples of dapps we built with it incl. this year's Devcon's collaboration stack.",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Community",
+ "id": "deep-dive-how-to-use-erc-3668-to-trustlessly-read-l2-data-from-l1",
+ "sourceId": "ZAKUY3",
+ "title": "Deep dive: how to use ERC- 3668 to trustlessly read L2 data from L1",
+ "description": "In this workshop, the ENS, Unruggable and Linea team will demonstrate how one can use ERC-3668 (aka. CCIP-read) to read L2 state trustlessly from L1, with concrete examples. Let us show you how it works!",
+ "track": "Layer 2",
+ "type": "Workshop",
+ "expertise": "Expert",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "mutual",
- "aid"
- ],
- "tags": [
- "Coordination",
- "Privacy",
- "Use Cases",
- "mutual",
- "aid",
- "Coordination",
- "Privacy",
- "Use Cases"
- ],
+ "tags": [],
+ "keywords": [],
+ "duration": 3425,
"language": "en",
- "speakers": [
- "andreas-tsamados"
- ],
+ "sources_swarmHash": "",
+ "sources_youtubeId": "L1pwtkKSTvs",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": "673483049dbb7a90e1e6f0c7",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673483049dbb7a90e1e6f0c7.vtt",
+ "transcript_text": " I think we're going to get started here. Okay, cool. Hey, everyone. This workshop is going to be about CCIP read. Maybe I'll hold this. Or maybe not. Okay, also known as ERC3668. I'm Greg Devrel at ENS Labs, and I'm going to be splitting this up with some friends from Linnea and Unruggable who you'll be hearing from a little bit later. Uh so just agenda, I know this is workshop so we're gonna try and limit the slides. But uh to keep it interesting we're gonna give you three different perspectives. I'm gonna give a brief overview. Uh Julian and Grant from Linnea are gonna share their perspective as kind of the first layer two team that really built and uses Trustless CCIP read infrastructure in production. And then Thomas from Unruggable is going to share a more generalized framework around how you can use Trustless CCIP read infrastructure in production as well. So if you haven't seen it, this is CCIP read or ERC 3668. It was authored by Nick Johnson, founder and lead developer of ENS, and you'll hear why that's relevant in a second. And before we dive in, we just want to answer two questions today. Why was it created and how is it used? And I guess before I do that, has anybody kind of written a contract that uses CCIP read before? Just to figure out the audience. Okay, so not very many. Cool. This is gonna be useful introduction then. So, CCIP read was written with Enus in mind, but written as an EIP so that it can be used for other things as well. Uh, and the reason it was written with Enus's in mind is because we have fairly unique needs. ENS is rooted in L1, which obviously is decentralized but expensive. And so we wanted to have a flexible system to where you can also basically fetch data from other places. And the first solution that people might think about is why not just deploy to a bunch of chains? And the reason we're unique is because we kind of can't do that. There has to be one central registry for where you have .eth names which is only a part of ENS but an important one. Uh and so we can't just kind of deploy to different chains. There can't be a world in which a .eth name is registered on multiple chains and different owners is just messy. So we have to have a central chain and we it's important for us to stay on main net for that central chain, or for that central registry because of decentralization and stuff like that. So an ideal solution to these kind of set of problems would be supporting reading data from any off-chain data source. And we really say off-chain, but it's like off L1 to be a little more explicit. So that could be a database, any generic API, or a layer two. And at the initial level, kind of like the first level of defense, both of these look the same, like off-chain is just off L1. But we'll kind of talk about how that difference comes into play in a minute. And similar to point one, based on where you read from, you'll have different sorts of verification logic. And so if you're reading from an off-chain data source, it will be a basic verification logic. If you're reading from an L2, you want something a little bit more complex and more kind of provable. And ultimately you don't want to add an extra burden on app developers that have to like do a bunch of whole custom stuff. And you also don't want a whole bunch of burden on gateway operators that might like push data to L1 by making a transaction and basically trying to mirror other chains because that's just expensive and not really sustainable. So the solution is this kind of diagram. I think you can see it pretty well. It's small on my screen, so I'll try and explain it. Basically, there are three parties. You have a client, you have a contract, and you have a gateway. Or in other words, it's like an application, a smart contract, and then an API. You know, the spec is that a client will call a function on a smart contract, as you do on any contract, and instead of returning data directly from, you know, internal storage or something it will actually return an error if you're implementing CCIP read and that error has a specific signature basically it's it's this off chain data error and this indicates to the client that it should send the call data that it gets back from that error to some URL which is also defined in the error and this kind",
"eventId": "devcon-7",
- "slot_start": 1731555000000,
- "slot_end": 1731556200000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1XQpLsYFcvAaRsWM6b13TUaTHGrXpSSKJ4fVPEoKkJfw"
+ "slot_start": 1731481200000,
+ "slot_end": 1731486600000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/1W0jwOLdutdtpuJNo6WvxKfcV8v0h4mUvf0CLm68DfjQ",
+ "resources_slides": null,
+ "speakers": [
+ "grant-southey",
+ "gregskrileth",
+ "julien",
+ "thomas-clowes"
+ ]
},
"vector": [
0,
@@ -208316,6 +207875,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -208541,6 +208101,9 @@
0,
0,
6,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -209141,9 +208704,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -209178,7 +208738,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -209217,7 +208776,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -209311,8 +208869,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -209623,16 +209179,16 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -209645,32 +209201,41 @@
},
{
"session": {
- "id": "deep-dive-how-to-use-erc-3668-to-trustlessly-read-l2-data-from-l1",
- "sourceId": "ZAKUY3",
- "title": "Deep dive: how to use ERC- 3668 to trustlessly read L2 data from L1",
- "description": "In this workshop, the ENS, Unruggable and Linea team will demonstrate how one can use ERC-3668 (aka. CCIP-read) to read L2 state trustlessly from L1, with concrete examples. Let us show you how it works!",
- "track": "Layer 2",
- "type": "Workshop",
- "expertise": "Expert",
+ "id": "deep-dive-into-fork-choice-compliance-for-ethereum-clients",
+ "sourceId": "D3XZKF",
+ "title": "Deep Dive into Fork Choice Compliance for Ethereum Clients",
+ "description": "In this talk we will share the design of the methodology checking the compliance of Ethereum consensus layer clients to the fork choice specification. The core of the methodology is based on the constraint solver models which allows to generate huge number of distinct test scenarios providing comprehensive coverage. At the current stage we have ended up at around 13,000 fork choice tests, but the test suite we developed allows to generate a million of tests and even more.",
+ "track": "Security",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Fork choice",
+ "model based testing",
+ "fuzz testing"
+ ],
+ "tags": [
+ "Core Protocol",
+ "Fuzzing",
+ "Testing",
+ "Core Protocol",
+ "Testing"
+ ],
"language": "en",
"speakers": [
- "julien",
- "grant-southey",
- "gregskrileth",
- "thomas-clowes"
+ "mikhail-kalinin",
+ "alex-vlasov"
],
"eventId": "devcon-7",
- "slot_start": 1731481200000,
- "slot_end": 1731486600000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/1W0jwOLdutdtpuJNo6WvxKfcV8v0h4mUvf0CLm68DfjQ"
+ "slot_start": 1731578400000,
+ "slot_end": 1731580200000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1MDK3dwXPQcTMGQIVnxa-4Kpkp17RJexPuQt0c3zp1_Q"
},
"vector": [
+ 6,
0,
0,
0,
@@ -209678,11 +209243,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -209902,10 +209462,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
0,
0,
0,
@@ -209914,6 +209470,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -210427,6 +209985,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -210444,6 +210003,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -210664,6 +210224,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -210984,11 +210545,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
2,
- 2,
0,
0,
0,
@@ -211006,46 +210567,53 @@
},
{
"session": {
- "id": "deep-dive-into-fork-choice-compliance-for-ethereum-clients",
- "sourceId": "D3XZKF",
- "title": "Deep Dive into Fork Choice Compliance for Ethereum Clients",
- "description": "In this talk we will share the design of the methodology checking the compliance of Ethereum consensus layer clients to the fork choice specification. The core of the methodology is based on the constraint solver models which allows to generate huge number of distinct test scenarios providing comprehensive coverage. At the current stage we have ended up at around 13,000 fork choice tests, but the test suite we developed allows to generate a million of tests and even more.",
- "track": "Security",
- "type": "Talk",
- "expertise": "Intermediate",
+ "id": "deep-dive-the-lp-pricing",
+ "sourceId": "CDPRCK",
+ "title": "Deep Dive the LP Pricing",
+ "description": "Accurate and robust oracle pricing is the backbone of DeFi. However, LP token prices can easily be manipulated if not calculated correctly.\r\nIn this talk, I will focus on how to calculate a \"fair price\" for LP tokens, ensuring security and accuracy. This includes LP token pricing for various protocols such as Uniswap V2, Uniswap V3, Trader Joe v2, Curve – sharing insights and implementations from my experience developing Alpha Homora, Stella, INIT Capital and INFINIT.",
+ "track": "Cryptoeconomics",
+ "type": "Lightning Talk",
+ "expertise": "Expert",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Fork choice",
- "model based testing",
- "fuzz testing"
- ],
"tags": [
- "Core Protocol",
- "Fuzzing",
- "Testing",
- "Core Protocol",
- "Testing"
+ "Security",
+ "Mechanism design",
+ "Economics",
+ "defi",
+ "Economics",
+ "Mechanism design",
+ "Security"
],
- "language": "en",
- "speakers": [
- "mikhail-kalinin",
- "alex-vlasov"
+ "keywords": [
+ "Math",
+ "Oracle price",
+ "DeFi"
],
+ "duration": 513,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "zsohxOn91vc",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": "6734717f9dbb7a90e112656b",
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731578400000,
- "slot_end": 1731580200000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1MDK3dwXPQcTMGQIVnxa-4Kpkp17RJexPuQt0c3zp1_Q"
+ "slot_start": 1731488400000,
+ "slot_end": 1731489000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1c2MfQGdbJapup-3V1uRqWXcF71JAgZPMM_0mp-IIXL8",
+ "resources_slides": null,
+ "speakers": [
+ "nipun-pitimanaaree"
+ ]
},
"vector": [
- 6,
- 0,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -211275,13 +210843,12 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -211800,6 +211367,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -211811,7 +211379,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -211828,6 +211395,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -211983,6 +211551,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -212033,7 +211602,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -212353,11 +211921,11 @@
0,
0,
0,
- 2,
0,
0,
0,
2,
+ 2,
0,
0,
0,
@@ -212375,52 +211943,43 @@
},
{
"session": {
- "id": "deep-dive-the-lp-pricing",
- "sourceId": "CDPRCK",
- "title": "Deep Dive the LP Pricing",
- "description": "Accurate and robust oracle pricing is the backbone of DeFi. However, LP token prices can easily be manipulated if not calculated correctly.\r\nIn this talk, I will focus on how to calculate a \"fair price\" for LP tokens, ensuring security and accuracy. This includes LP token pricing for various protocols such as Uniswap V2, Uniswap V3, Trader Joe v2, Curve – sharing insights and implementations from my experience developing Alpha Homora, Stella, INIT Capital and INFINIT.",
- "track": "Cryptoeconomics",
- "type": "Lightning Talk",
- "expertise": "Expert",
+ "id": "defcon-at-devcon-a-table-top-experience",
+ "sourceId": "P9DRXY",
+ "title": "Defcon at Devcon: A table top experience",
+ "description": "It's 3am and your phone is blowing up—Telegram, Signal, Discord, X—all are saying your project just got rekt. Your team is panicking and begging you to sign off on a quick protocol upgrade. What do you do?\r\n\r\nJoin our workshop to get hands-on with crisis management in web3. Learn to handle attacks, keep cool under pressure, and manage your stakeholders. By the end, you'll turn this crisis into manageable challenges, protect your project, and keep building.",
+ "track": "Security",
+ "type": "Workshop",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Security",
- "Mechanism design",
- "Economics",
- "defi",
- "Economics",
- "Mechanism design",
- "Security"
- ],
"keywords": [
- "Math",
- "Oracle price",
- "DeFi"
+ "Tabletop",
+ "Incident Response",
+ "Threat Intelligence"
+ ],
+ "tags": [
+ "Best Practices",
+ "Hacks",
+ "Event monitoring",
+ "threat",
+ "intelligence",
+ "Best Practices",
+ "Event monitoring",
+ "Hacks"
],
- "duration": 513,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "zsohxOn91vc",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": "6734717f9dbb7a90e112656b",
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731488400000,
- "slot_end": 1731489000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1c2MfQGdbJapup-3V1uRqWXcF71JAgZPMM_0mp-IIXL8",
- "resources_slides": null,
"speakers": [
- "nipun-pitimanaaree"
- ]
+ "heidi-wilder",
+ "peter-kacherginsky"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731638700000,
+ "slot_end": 1731645900000,
+ "slot_roomId": "classroom-b",
+ "resources_presentation": "https://docs.google.com/presentation/d/1s2NkLIuneQtBUvfLLlkFlOE3IWetDHM6-4OAQMItN-0"
},
"vector": [
- 0,
- 0,
6,
0,
0,
@@ -212656,14 +212215,11 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -213171,14 +212727,12 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -213362,7 +212916,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -213426,6 +212979,11 @@
0,
0,
0,
+ 2,
+ 2,
+ 2,
+ 2,
+ 0,
0,
0,
0,
@@ -213732,11 +213290,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
2,
- 2,
0,
0,
0,
@@ -213754,41 +213312,34 @@
},
{
"session": {
- "id": "defcon-at-devcon-a-table-top-experience",
- "sourceId": "P9DRXY",
- "title": "Defcon at Devcon: A table top experience",
- "description": "It's 3am and your phone is blowing up—Telegram, Signal, Discord, X—all are saying your project just got rekt. Your team is panicking and begging you to sign off on a quick protocol upgrade. What do you do?\r\n\r\nJoin our workshop to get hands-on with crisis management in web3. Learn to handle attacks, keep cool under pressure, and manage your stakeholders. By the end, you'll turn this crisis into manageable challenges, protect your project, and keep building.",
+ "id": "defi-cant-move-forward-without-clear-signing-let-me-change-your-mind",
+ "sourceId": "9KWRRJ",
+ "title": "DeFi Can’t Move Forward Without Clear Signing: Let Me Change Your Mind",
+ "description": "Blind signing has been the default way of signing transactions in DeFi, but let’s be honest: as an industry we are shooting ourselves and our users in the foot by continuing to throw caution to the wind. \r\n\r\nWe want to make it easy to implement clear signing for every dAapp, minimizing the work required for developers to make the ecosystem more approachable and secure.\r\n\r\nBlind signing is an existential threat to what we do, it’s time to change it, and we need your help.",
"track": "Security",
- "type": "Workshop",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Tabletop",
- "Incident Response",
- "Threat Intelligence"
+ "Clear signing",
+ "transactions"
],
"tags": [
- "Best Practices",
- "Hacks",
- "Event monitoring",
- "threat",
- "intelligence",
- "Best Practices",
- "Event monitoring",
- "Hacks"
+ "Open Source Software",
+ "Security",
+ "UI/UX"
],
"language": "en",
"speakers": [
- "heidi-wilder",
- "peter-kacherginsky"
+ "charles-guillemet"
],
"eventId": "devcon-7",
- "slot_start": 1731638700000,
- "slot_end": 1731645900000,
- "slot_roomId": "classroom-b",
- "resources_presentation": "https://docs.google.com/presentation/d/1s2NkLIuneQtBUvfLLlkFlOE3IWetDHM6-4OAQMItN-0"
+ "slot_start": 1731409200000,
+ "slot_end": 1731409800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1oJyQ2nbiJ3dVyeigOw76p6xClrq9LFrInO05tg2QbVg"
},
"vector": [
6,
@@ -214029,10 +213580,9 @@
0,
0,
0,
- 6,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -214541,6 +214091,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -214574,7 +214125,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -214600,6 +214150,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -214638,6 +214189,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -214794,10 +214346,6 @@
0,
0,
0,
- 2,
- 2,
- 2,
- 2,
0,
0,
0,
@@ -215108,9 +214656,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -215126,38 +214674,35 @@
},
{
"session": {
- "id": "defi-cant-move-forward-without-clear-signing-let-me-change-your-mind",
- "sourceId": "9KWRRJ",
- "title": "DeFi Can’t Move Forward Without Clear Signing: Let Me Change Your Mind",
- "description": "Blind signing has been the default way of signing transactions in DeFi, but let’s be honest: as an industry we are shooting ourselves and our users in the foot by continuing to throw caution to the wind. \r\n\r\nWe want to make it easy to implement clear signing for every dAapp, minimizing the work required for developers to make the ecosystem more approachable and secure.\r\n\r\nBlind signing is an existential threat to what we do, it’s time to change it, and we need your help.",
- "track": "Security",
- "type": "Lightning Talk",
+ "id": "defragmenting-ethereum-interoperability-and-the-superchain",
+ "sourceId": "YEQLR8",
+ "title": "Defragmenting Ethereum - Interoperability and the Superchain",
+ "description": "With the proliferation of L2s and Dencun (4844), Ethereum has scaled. However, we have a new challenge -- fragmentation.\r\n\r\nNow we're introducing various interoperability standards across Ethereum and Superchain ecosystem from intents to low latency cross chain bridging primitives. What are these standards and what will enable? How can we create scalable and composable blockspace which enables application developers to onboard the rest of the internet?",
+ "track": "Layer 2",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Clear signing",
- "transactions"
+ "superchain",
+ "OP Stack",
+ "optimism"
],
"tags": [
- "Open Source Software",
- "Security",
- "UI/UX"
+ "optimism"
],
"language": "en",
"speakers": [
- "charles-guillemet"
+ "karl-floersch"
],
"eventId": "devcon-7",
- "slot_start": 1731409200000,
- "slot_end": 1731409800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1oJyQ2nbiJ3dVyeigOw76p6xClrq9LFrInO05tg2QbVg"
+ "slot_start": 1731495600000,
+ "slot_end": 1731497400000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/18NUBFhBTGUc1VCTGb7xM78rgqQTtMu78w-hWIYbTYxA"
},
"vector": [
- 6,
- 0,
0,
0,
0,
@@ -215165,6 +214710,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -215396,9 +214942,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -215908,7 +215454,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -215967,7 +215512,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -216006,7 +215550,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -216163,6 +215706,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -216473,9 +216017,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -216491,33 +216035,43 @@
},
{
"session": {
- "id": "defragmenting-ethereum-interoperability-and-the-superchain",
- "sourceId": "YEQLR8",
- "title": "Defragmenting Ethereum - Interoperability and the Superchain",
- "description": "With the proliferation of L2s and Dencun (4844), Ethereum has scaled. However, we have a new challenge -- fragmentation.\r\n\r\nNow we're introducing various interoperability standards across Ethereum and Superchain ecosystem from intents to low latency cross chain bridging primitives. What are these standards and what will enable? How can we create scalable and composable blockspace which enables application developers to onboard the rest of the internet?",
- "track": "Layer 2",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "degen-incentives-for-regen-outcomes",
+ "sourceId": "MNWVFW",
+ "title": "Degen incentives for Regen outcomes",
+ "description": "Degens (financial speculators) and Regens (blockchain altruists) don't like each other. But there's a lot that can be achieved if both tribes work together. In this panel we'll explore those projects that embrace both energies to find balance in the force and unlock Ethereum’s potential.",
+ "track": "Coordination",
+ "type": "Panel",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "superchain",
- "OP Stack",
- "optimism"
+ "Ethereum Culture",
+ "Ethereum Community",
+ "degens🤝regens"
],
"tags": [
- "optimism"
+ "Ethereum for Good",
+ "Regenerative Applications",
+ "Product-market fit",
+ "regen",
+ "degens",
+ "Ethereum for Good",
+ "Product-market fit",
+ "Regenerative Applications"
],
"language": "en",
"speakers": [
- "karl-floersch"
+ "griff-green",
+ "nico-gallardo",
+ "james-kiernan",
+ "lauren-luz"
],
"eventId": "devcon-7",
- "slot_start": 1731495600000,
- "slot_end": 1731497400000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/18NUBFhBTGUc1VCTGb7xM78rgqQTtMu78w-hWIYbTYxA"
+ "slot_start": 1731643200000,
+ "slot_end": 1731646800000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1VL2_zkuomzUJ59v6VkJCzFGACRwHLUks6cXhys2kzmA"
},
"vector": [
0,
@@ -216527,11 +216081,12 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -216762,6 +216317,20 @@
0,
0,
6,
+ 6,
+ 6,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -217312,6 +216881,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -217372,6 +216949,12 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
0,
0,
0,
@@ -217495,6 +217078,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -217527,38 +217112,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -217837,12 +217390,10 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -217855,47 +217406,38 @@
},
{
"session": {
- "id": "degen-incentives-for-regen-outcomes",
- "sourceId": "MNWVFW",
- "title": "Degen incentives for Regen outcomes",
- "description": "Degens (financial speculators) and Regens (blockchain altruists) don't like each other. But there's a lot that can be achieved if both tribes work together. In this panel we'll explore those projects that embrace both energies to find balance in the force and unlock Ethereum’s potential.",
- "track": "Coordination",
- "type": "Panel",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "demand-based-recurring-fees-in-practice",
+ "sourceId": "GWBWPE",
+ "title": "Demand-based recurring fees in practice",
+ "description": "ALL 4 letter .COMs have been taken since 2013. Yet most only have a few natural buyers; hence, speculation doesn't make that market more efficient.\r\n\r\nYet, in crypto-economics, we can already transcend private property to deter the monopolization of digital assets like domains. \r\n\r\nThis talk explores solutions from Weyl, Posner, and Henry George. We'll show how pricing and allocative efficiency can be improved through Georgist land value tax for assets like real estate, domain names, or ad space.",
+ "track": "Cryptoeconomics",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Ethereum Culture",
- "Ethereum Community",
- "degens🤝regens"
+ "pricing"
],
"tags": [
- "Ethereum for Good",
- "Regenerative Applications",
- "Product-market fit",
- "regen",
- "degens",
- "Ethereum for Good",
- "Product-market fit",
- "Regenerative Applications"
+ "Economics",
+ "Mechanism design",
+ "Quadratic Voting"
],
"language": "en",
"speakers": [
- "griff-green",
- "nico-gallardo",
- "james-kiernan",
- "lauren-luz"
+ "timdaub"
],
"eventId": "devcon-7",
- "slot_start": 1731643200000,
- "slot_end": 1731646800000,
+ "slot_start": 1731495000000,
+ "slot_end": 1731496800000,
"slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1VL2_zkuomzUJ59v6VkJCzFGACRwHLUks6cXhys2kzmA"
+ "resources_presentation": "https://docs.google.com/presentation/d/15PZ749rPc9HedXMUE_qdwIMFPhSIfM_Qt1GSmEy4JsU"
},
"vector": [
0,
0,
+ 6,
0,
0,
0,
@@ -217905,7 +217447,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -218136,14 +217677,11 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -218653,6 +218191,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -218680,6 +218219,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -218704,7 +218244,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -218772,12 +218311,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -218856,6 +218393,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -218902,8 +218440,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -219213,10 +218749,12 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -219229,37 +218767,53 @@
},
{
"session": {
- "id": "demand-based-recurring-fees-in-practice",
- "sourceId": "GWBWPE",
- "title": "Demand-based recurring fees in practice",
- "description": "ALL 4 letter .COMs have been taken since 2013. Yet most only have a few natural buyers; hence, speculation doesn't make that market more efficient.\r\n\r\nYet, in crypto-economics, we can already transcend private property to deter the monopolization of digital assets like domains. \r\n\r\nThis talk explores solutions from Weyl, Posner, and Henry George. We'll show how pricing and allocative efficiency can be improved through Georgist land value tax for assets like real estate, domain names, or ad space.",
- "track": "Cryptoeconomics",
- "type": "Talk",
+ "id": "demystifying-smart-contract-security-facts-and-fallacies",
+ "sourceId": "VXRSPU",
+ "title": "Demystifying Smart Contract Security: Facts & Fallacies",
+ "description": "Smart contract security is of critical importance as the Ethereum ecosystem rapidly expands across different infrastructures & applications. However, there exist serious gaps and misconceptions about security as it relates to smart contract design, development, validation, tooling, offchain components, audits, bug bounties, monitoring & incident response.\r\n\r\nThis panel brings together six recognized researchers within the Ethereum security ecosystem to help demystify facts from fallacies.",
+ "track": "Security",
+ "type": "Panel",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "pricing"
+ "Smart",
+ "Contract",
+ "Security"
],
"tags": [
- "Economics",
- "Mechanism design",
- "Quadratic Voting"
+ "Security",
+ "Best Practices",
+ "Hacks",
+ "Formal Verification",
+ "Auditing",
+ "Bounties",
+ "smart",
+ "contracts",
+ "Auditing",
+ "Best Practices",
+ "Bounties",
+ "Formal Verification",
+ "Hacks",
+ "Security"
],
"language": "en",
"speakers": [
- "timdaub"
+ "josselin-feist",
+ "0xrajeev",
+ "matthias-egli",
+ "mehdi-zerouali",
+ "mooly-sagiv",
+ "harikrishnan-mulackal"
],
"eventId": "devcon-7",
- "slot_start": 1731495000000,
- "slot_end": 1731496800000,
+ "slot_start": 1731657600000,
+ "slot_end": 1731661200000,
"slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/15PZ749rPc9HedXMUE_qdwIMFPhSIfM_Qt1GSmEy4JsU"
+ "resources_presentation": "https://docs.google.com/presentation/d/1XzYtYO3NQtFr1B6HDE_M1alRWMpmL2iUvLkfcX4Z02g"
},
"vector": [
- 0,
- 0,
6,
0,
0,
@@ -219504,20 +219058,15 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
+ 6,
+ 6,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -220014,10 +219563,10 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -220166,6 +219715,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -220210,6 +219760,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -220219,8 +219770,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -220264,12 +219813,16 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
+ 2,
+ 2,
0,
0,
0,
@@ -220575,9 +220128,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -220593,53 +220146,39 @@
},
{
"session": {
- "id": "demystifying-smart-contract-security-facts-and-fallacies",
- "sourceId": "VXRSPU",
- "title": "Demystifying Smart Contract Security: Facts & Fallacies",
- "description": "Smart contract security is of critical importance as the Ethereum ecosystem rapidly expands across different infrastructures & applications. However, there exist serious gaps and misconceptions about security as it relates to smart contract design, development, validation, tooling, offchain components, audits, bug bounties, monitoring & incident response.\r\n\r\nThis panel brings together six recognized researchers within the Ethereum security ecosystem to help demystify facts from fallacies.",
- "track": "Security",
- "type": "Panel",
- "expertise": "Intermediate",
- "audience": "Developer",
+ "id": "demystifying-solo-staking-struggles",
+ "sourceId": "9KV8UQ",
+ "title": "Demystifying solo staking struggles",
+ "description": "Is solo staking easy or hard? What are stakers struggling with? I will go over the main issues facing solo stakers and what can be done about it. I will talk about the importance of solo stakers.",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Stakers/Validators",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Smart",
- "Contract",
- "Security"
+ "beginners"
],
"tags": [
- "Security",
- "Best Practices",
- "Hacks",
- "Formal Verification",
- "Auditing",
- "Bounties",
- "smart",
- "contracts",
- "Auditing",
"Best Practices",
- "Bounties",
- "Formal Verification",
- "Hacks",
- "Security"
+ "Home staking",
+ "Staking"
],
"language": "en",
"speakers": [
- "josselin-feist",
- "0xrajeev",
- "matthias-egli",
- "mehdi-zerouali",
- "mooly-sagiv",
- "harikrishnan-mulackal"
+ "remy-roy"
],
"eventId": "devcon-7",
- "slot_start": 1731657600000,
- "slot_end": 1731661200000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1XzYtYO3NQtFr1B6HDE_M1alRWMpmL2iUvLkfcX4Z02g"
+ "slot_start": 1731642600000,
+ "slot_end": 1731643200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/12_jK1k9PlkGv-cHbW_ySIi8eDOSs8LavI_tRw_CJE10"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
6,
0,
0,
@@ -220887,11 +220426,8 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
- 6,
+ 0,
+ 0,
6,
0,
0,
@@ -221392,7 +220928,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -221420,10 +220955,11 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -221474,6 +221010,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -221516,6 +221053,19 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -221544,7 +221094,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -221589,7 +221138,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -221643,20 +221191,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -221959,11 +221493,9 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
+ 2,
0,
0,
0,
@@ -221975,45 +221507,53 @@
},
{
"session": {
- "id": "demystifying-solo-staking-struggles",
- "sourceId": "9KV8UQ",
- "title": "Demystifying solo staking struggles",
- "description": "Is solo staking easy or hard? What are stakers struggling with? I will go over the main issues facing solo stakers and what can be done about it. I will talk about the importance of solo stakers.",
- "track": "Core Protocol",
+ "id": "depin-pushing-decentralization-beyond-blockchain",
+ "sourceId": "Q8QPSF",
+ "title": "DePIN: Pushing Decentralization Beyond Blockchain",
+ "description": "Explore the revolutionary world of Decentralized Physical Infrastructure Networks (DePIN), where blockchain meets real-world applications. This talk delves into DePIN's core concepts, from token economics to governance, highlighting its potential to transform industries. We'll examine successful projects, technological underpinnings, and future trends. Using Huddle01's innovative approach to decentralizing real-time communication as a case study, we'll demonstrate DePIN's practical impact. Join",
+ "track": "Real World Ethereum",
"type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Stakers/Validators",
+ "expertise": "Intermediate",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "beginners"
+ "Distributed Systems",
+ "Physical Infrastructure",
+ "Real Time Communication (RTC)"
],
"tags": [
- "Best Practices",
- "Home staking",
- "Staking"
+ "Architecture",
+ "Decentralization",
+ "DePIN",
+ "Tokenomics",
+ "communication",
+ "real",
+ "time",
+ "rtc",
+ "Architecture",
+ "Decentralization",
+ "DePIN",
+ "Tokenomics"
],
"language": "en",
"speakers": [
- "remy-roy"
+ "akshit-gupta"
],
"eventId": "devcon-7",
- "slot_start": 1731642600000,
- "slot_end": 1731643200000,
+ "slot_start": 1731579600000,
+ "slot_end": 1731580200000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/12_jK1k9PlkGv-cHbW_ySIi8eDOSs8LavI_tRw_CJE10"
+ "resources_presentation": "https://docs.google.com/presentation/d/1frO1LBrX3h2e6LoJqHpvDElvChyEEDg6CFrkzwQt5VY"
},
"vector": [
0,
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -222257,12 +221797,11 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -222779,6 +222318,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -222787,7 +222327,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -222801,6 +222340,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -222818,6 +222358,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -222842,7 +222383,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -222858,6 +222398,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -222885,7 +222426,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -223016,6 +222556,9 @@
0,
0,
0,
+ 2,
+ 2,
+ 2,
0,
0,
0,
@@ -223314,6 +222857,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -223327,10 +222871,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -223339,44 +222879,33 @@
},
{
"session": {
- "id": "depin-pushing-decentralization-beyond-blockchain",
- "sourceId": "Q8QPSF",
- "title": "DePIN: Pushing Decentralization Beyond Blockchain",
- "description": "Explore the revolutionary world of Decentralized Physical Infrastructure Networks (DePIN), where blockchain meets real-world applications. This talk delves into DePIN's core concepts, from token economics to governance, highlighting its potential to transform industries. We'll examine successful projects, technological underpinnings, and future trends. Using Huddle01's innovative approach to decentralizing real-time communication as a case study, we'll demonstrate DePIN's practical impact. Join",
+ "id": "desci-co-designing-the-future-of-science",
+ "sourceId": "DCHCYW",
+ "title": "DeSci: Co-Designing The Future of Science",
+ "description": "Connect with leaders in the DeSci Space to co-design the future of science. \r\n\r\nThis workshop aims to connect: \r\n- Developers & technical leaders by elevating your technology to be used by the DeSci community\r\n- Scientists & former scientists who can share needs in science to be solved for\r\n- DeSci leaders who can showcase what is happening now in DeSci and the visions the space is working towards \r\n\r\nLet's build a more collaborative, trustful, and effective scientific future together!",
"track": "Real World Ethereum",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Academic",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Distributed Systems",
- "Physical Infrastructure",
- "Real Time Communication (RTC)"
+ "Science"
],
"tags": [
- "Architecture",
- "Decentralization",
- "DePIN",
- "Tokenomics",
- "communication",
- "real",
- "time",
- "rtc",
- "Architecture",
- "Decentralization",
- "DePIN",
- "Tokenomics"
+ "science",
+ "Data Availability",
+ "DeSci"
],
"language": "en",
"speakers": [
- "akshit-gupta"
+ "erin-magennis"
],
"eventId": "devcon-7",
- "slot_start": 1731579600000,
- "slot_end": 1731580200000,
+ "slot_start": 1731659400000,
+ "slot_end": 1731660000000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1frO1LBrX3h2e6LoJqHpvDElvChyEEDg6CFrkzwQt5VY"
+ "resources_presentation": "https://docs.google.com/presentation/d/1RHyT56CbMgegV6NNemWv9dElkUsDZAzoG2HGnU3oSVo"
},
"vector": [
0,
@@ -223633,6 +223162,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -224153,7 +223683,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -224175,7 +223704,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -224193,10 +223721,10 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -224233,7 +223761,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -224264,6 +223791,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -224393,8 +223921,6 @@
0,
0,
2,
- 2,
- 2,
0,
0,
0,
@@ -224698,7 +224224,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -224706,6 +224231,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -224714,33 +224240,37 @@
},
{
"session": {
- "id": "desci-co-designing-the-future-of-science",
- "sourceId": "DCHCYW",
- "title": "DeSci: Co-Designing The Future of Science",
- "description": "Connect with leaders in the DeSci Space to co-design the future of science. \r\n\r\nThis workshop aims to connect: \r\n- Developers & technical leaders by elevating your technology to be used by the DeSci community\r\n- Scientists & former scientists who can share needs in science to be solved for\r\n- DeSci leaders who can showcase what is happening now in DeSci and the visions the space is working towards \r\n\r\nLet's build a more collaborative, trustful, and effective scientific future together!",
+ "id": "desci-on-trial-two-years-2000-eth-11-projects-2bn-data-points-on-ethereum-has-desci-advanced-science",
+ "sourceId": "MZ3RLT",
+ "title": "DeSci on Trial: Two Years, 2000 ETH, 11 Projects, 2bn data points on Ethereum - has DeSci advanced science?",
+ "description": "Two years, 11 projects, $5M in funding for on chain science - what has DeSci on Ethereum really achieved? We'll critically examine key projects like Copenhagen University's longevity research and Newcastle's autophagy activation, assessing scientific rigor, web3 benefits, and real-world impact. Join us for an honest look at DeSci's promises vs. realities, featuring a live researcher update and helping shape a governance proposal on one of the presented projects.",
"track": "Real World Ethereum",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Academic",
+ "expertise": "Beginner",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Science"
+ "Impact"
],
"tags": [
- "science",
- "Data Availability",
- "DeSci"
+ "Permissionless",
+ "Use Cases",
+ "DeSci",
+ "impact",
+ "DeSci",
+ "Permissionless",
+ "Use Cases"
],
"language": "en",
"speakers": [
- "erin-magennis"
+ "paul-kohlhaas"
],
"eventId": "devcon-7",
- "slot_start": 1731659400000,
- "slot_end": 1731660000000,
+ "slot_start": 1731658800000,
+ "slot_end": 1731659400000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1RHyT56CbMgegV6NNemWv9dElkUsDZAzoG2HGnU3oSVo"
+ "resources_presentation": "https://docs.google.com/presentation/d/1GqW9KTYWAB1IHrlktGM0ntHgWK-2umJNkyohBO811gU"
},
"vector": [
0,
@@ -224998,11 +224528,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -225562,7 +225089,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -225575,6 +225101,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -225760,6 +225287,7 @@
0,
0,
2,
+ 2,
0,
0,
0,
@@ -226056,11 +225584,11 @@
0,
0,
0,
- 2,
- 0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -226069,7 +225597,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -226078,37 +225605,41 @@
},
{
"session": {
- "id": "desci-on-trial-two-years-2000-eth-11-projects-2bn-data-points-on-ethereum-has-desci-advanced-science",
- "sourceId": "MZ3RLT",
- "title": "DeSci on Trial: Two Years, 2000 ETH, 11 Projects, 2bn data points on Ethereum - has DeSci advanced science?",
- "description": "Two years, 11 projects, $5M in funding for on chain science - what has DeSci on Ethereum really achieved? We'll critically examine key projects like Copenhagen University's longevity research and Newcastle's autophagy activation, assessing scientific rigor, web3 benefits, and real-world impact. Join us for an honest look at DeSci's promises vs. realities, featuring a live researcher update and helping shape a governance proposal on one of the presented projects.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Research",
+ "id": "designing-an-end-to-end-solution-for-based-preconfirmations",
+ "sourceId": "CRWBCC",
+ "title": "Designing an End to End Solution for Based Preconfirmations",
+ "description": "This workshop provides the audience with a foundation for building an end-to-end solution to deliver fast preconfirmation of transactions on a based-rollup like Taiko. In addition to understanding the basics of based sequencing and preconfirmations, attendees will learn about settling these preconfirmations as an Eigenlayer AVS, designing the AVS client, syncing L2 state using preconfirmed blocks, preconfer election, and managing a proposer lookahead using Beacon state within smart contracts.",
+ "track": "Layer 2",
+ "type": "Workshop",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Impact"
+ "Preconfirmations",
+ "Based Rollups",
+ "Based Sequencing"
],
"tags": [
- "Permissionless",
- "Use Cases",
- "DeSci",
- "impact",
- "DeSci",
- "Permissionless",
- "Use Cases"
+ "Layer 2s",
+ "Rollups",
+ "User Experience",
+ "sequencer",
+ "based",
+ "Layer 2s",
+ "Rollups",
+ "User Experience"
],
"language": "en",
"speakers": [
- "paul-kohlhaas"
+ "anshu-jalan",
+ "ahmad-bitar"
],
"eventId": "devcon-7",
- "slot_start": 1731658800000,
- "slot_end": 1731659400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1GqW9KTYWAB1IHrlktGM0ntHgWK-2umJNkyohBO811gU"
+ "slot_start": 1731655800000,
+ "slot_end": 1731661200000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/14eqnMC0_aJ3IguPD2egqY1ojHSZRxc4QPo5D4RhCje8"
},
"vector": [
0,
@@ -226117,6 +225648,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -226368,6 +225900,9 @@
0,
0,
6,
+ 6,
+ 0,
+ 0,
0,
0,
0,
@@ -226872,6 +226407,22 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -226882,6 +226433,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -226898,6 +226457,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -226997,7 +226558,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -227128,42 +226688,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -227426,11 +226950,15 @@
0,
0,
0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
2,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -227446,41 +226974,44 @@
},
{
"session": {
- "id": "designing-an-end-to-end-solution-for-based-preconfirmations",
- "sourceId": "CRWBCC",
- "title": "Designing an End to End Solution for Based Preconfirmations",
- "description": "This workshop provides the audience with a foundation for building an end-to-end solution to deliver fast preconfirmation of transactions on a based-rollup like Taiko. In addition to understanding the basics of based sequencing and preconfirmations, attendees will learn about settling these preconfirmations as an Eigenlayer AVS, designing the AVS client, syncing L2 state using preconfirmed blocks, preconfer election, and managing a proposer lookahead using Beacon state within smart contracts.",
- "track": "Layer 2",
+ "id": "designing-and-launching-a-retroround-incentivize-what-matters",
+ "sourceId": "39AVKD",
+ "title": "Designing and launching a RetroRound - Incentivize what matters",
+ "description": "Learn how to design, develop and launch a retroactive funding round. In this workshop we’ll explore the differences, similarities and best practices for running a local and ecosystem RetroRound. Participants will be able to set clear goals, define impactful behaviors to be incentivized, scope technical roadmaps, and formulate a sustainable strategy to fund public goods. Ideal for emerging markets community leaders and web3 Ecosystems looking for new resilient and diverse funding strategies.",
+ "track": "Coordination",
"type": "Workshop",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Preconfirmations",
- "Based Rollups",
- "Based Sequencing"
+ "Emerging markets",
+ "Grant Program Design",
+ ""
],
"tags": [
- "Layer 2s",
- "Rollups",
- "User Experience",
- "sequencer",
- "based",
- "Layer 2s",
- "Rollups",
- "User Experience"
+ "RPGF",
+ "Quadratic Voting",
+ "Public good",
+ "Design",
+ "Mechanism design",
+ "program",
+ "grants",
+ "Mechanism design",
+ "Public good",
+ "Quadratic Voting",
+ "RPGF"
],
"language": "en",
"speakers": [
- "anshu-jalan",
- "ahmad-bitar"
+ "launamu",
+ "sejal-rekhan"
],
"eventId": "devcon-7",
- "slot_start": 1731655800000,
- "slot_end": 1731661200000,
+ "slot_start": 1731571200000,
+ "slot_end": 1731576600000,
"slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/14eqnMC0_aJ3IguPD2egqY1ojHSZRxc4QPo5D4RhCje8"
+ "resources_presentation": "https://docs.google.com/presentation/d/1GTU723iYMOTD9COHjYQdSKNFi7gSZc88-BnP7Co9jE4"
},
"vector": [
0,
@@ -227490,15 +227021,11 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -227740,14 +227267,14 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -228239,9 +227766,11 @@
0,
0,
0,
+ 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -228251,7 +227780,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -228277,10 +227805,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -228301,7 +227827,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -228381,6 +227906,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -228446,6 +227972,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -228502,6 +228029,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -228796,9 +228325,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
2,
0,
@@ -228807,6 +228333,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -228818,48 +228346,42 @@
},
{
"session": {
- "id": "designing-and-launching-a-retroround-incentivize-what-matters",
- "sourceId": "39AVKD",
- "title": "Designing and launching a RetroRound - Incentivize what matters",
- "description": "Learn how to design, develop and launch a retroactive funding round. In this workshop we’ll explore the differences, similarities and best practices for running a local and ecosystem RetroRound. Participants will be able to set clear goals, define impactful behaviors to be incentivized, scope technical roadmaps, and formulate a sustainable strategy to fund public goods. Ideal for emerging markets community leaders and web3 Ecosystems looking for new resilient and diverse funding strategies.",
- "track": "Coordination",
- "type": "Workshop",
- "expertise": "Beginner",
+ "id": "designing-conditional-markets-and-futarchy",
+ "sourceId": "EWJNVJ",
+ "title": "Designing Conditional Markets and Futarchy",
+ "description": "Conditional markets allow predicting outcomes from potential decisions, enabling what is called futarchy governance, but key design questions remain open. We'll examine specific challenges: aligning founders with investors in protocols, encouraging meaningful participation in decentralized governance, and integrating futarchy modules into existing governance systems.",
+ "track": "Cryptoeconomics",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Emerging markets",
- "Grant Program Design",
- ""
+ "Prediction",
+ "markets"
],
"tags": [
- "RPGF",
- "Quadratic Voting",
- "Public good",
- "Design",
- "Mechanism design",
- "program",
- "grants",
- "Mechanism design",
- "Public good",
- "Quadratic Voting",
- "RPGF"
+ "market",
+ "prediction",
+ "DAO",
+ "Futarchy",
+ "Public good"
],
"language": "en",
"speakers": [
- "launamu",
- "sejal-rekhan"
+ "kaseth",
+ "robin-hanson"
],
"eventId": "devcon-7",
- "slot_start": 1731571200000,
- "slot_end": 1731576600000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/1GTU723iYMOTD9COHjYQdSKNFi7gSZc88-BnP7Co9jE4"
+ "slot_start": 1731487800000,
+ "slot_end": 1731489600000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1xu1ruVYDwVrtPaBTfIRAfXMJa5j_5CZosQxtJM57H9c"
},
"vector": [
0,
0,
+ 6,
0,
0,
0,
@@ -228869,8 +228391,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -229066,6 +228586,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -229117,10 +228638,9 @@
0,
0,
0,
- 6,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -229613,11 +229133,9 @@
0,
0,
0,
- 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -229643,8 +229161,11 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -229708,6 +229229,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -229715,11 +229237,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -229753,7 +229275,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -229819,7 +229340,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -229877,8 +229397,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -230171,9 +229689,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -230193,46 +229711,39 @@
},
{
"session": {
- "id": "designing-conditional-markets-and-futarchy",
- "sourceId": "EWJNVJ",
- "title": "Designing Conditional Markets and Futarchy",
- "description": "Conditional markets allow predicting outcomes from potential decisions, enabling what is called futarchy governance, but key design questions remain open. We'll examine specific challenges: aligning founders with investors in protocols, encouraging meaningful participation in decentralized governance, and integrating futarchy modules into existing governance systems.",
- "track": "Cryptoeconomics",
+ "id": "devcon-sea-overview",
+ "sourceId": "HXNYDR",
+ "title": "Devcon SEA Overview",
+ "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Community",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Prediction",
- "markets"
- ],
- "tags": [
- "market",
- "prediction",
- "DAO",
- "Futarchy",
- "Public good"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
"speakers": [
- "kaseth",
- "robin-hanson"
+ "skylar-weaver",
+ "nathan-sexer"
],
"eventId": "devcon-7",
- "slot_start": 1731487800000,
- "slot_end": 1731489600000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1xu1ruVYDwVrtPaBTfIRAfXMJa5j_5CZosQxtJM57H9c"
+ "slot_start": 1731385800000,
+ "slot_end": 1731388500000,
+ "slot_roomId": "main-stage",
+ "sources_youtubeId": "c8suX-_PTo8",
+ "sources_swarmHash": "6579559384c3752ff4c849eff1d48dbe1dfc815f78de54dc6debbd2a36b5e991",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Qo0Nhlnmak6ecCzF_nhTStunc63frayP5RYA5bLD3TQ"
},
"vector": [
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -230405,6 +229916,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -230488,7 +230000,6 @@
0,
0,
6,
- 6,
0,
0,
0,
@@ -231011,11 +230522,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -231079,33 +230587,34 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -231542,14 +231051,13 @@
2,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -231561,30 +231069,40 @@
},
{
"session": {
- "id": "devcon-sea-overview",
- "sourceId": "HXNYDR",
- "title": "Devcon SEA Overview",
- "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.",
- "track": "Real World Ethereum",
+ "id": "developing-and-using-a-modular-folding-schemes-library",
+ "sourceId": "PPFPQY",
+ "title": "Developing and using a modular folding schemes library",
+ "description": "We will present Sonobe, a modular folding-schemes library. It currently features implementations of Nova, CycleFold, Hypernova and ProtoGalaxy schemes and is compatible with a wide range of R1CS arithmetization libraries. we will briefly discuss what folding schemes are and how they fit into IVC-style proof systems. Next, we will explain how Sonobe was built and what features it supports. Finally, we will cover what has been built with Sonobe and how developers can start using it today.",
+ "track": "Applied Cryptography",
"type": "Talk",
- "expertise": "",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Folding schemes",
+ "IVC",
+ "Nova"
+ ],
+ "tags": [
+ "Libraries",
+ "Zero-Knowledge",
+ "Cryptography",
+ "nova",
+ "Cryptography",
+ "Libraries",
+ "Zero-Knowledge"
+ ],
"language": "en",
"speakers": [
- "skylar-weaver",
- "nathan-sexer"
+ "pierre-daix-moreux",
+ "arnaucube"
],
"eventId": "devcon-7",
- "slot_start": 1731385800000,
- "slot_end": 1731388500000,
- "slot_roomId": "main-stage",
- "sources_youtubeId": "c8suX-_PTo8",
- "sources_swarmHash": "6579559384c3752ff4c849eff1d48dbe1dfc815f78de54dc6debbd2a36b5e991",
- "resources_presentation": "https://docs.google.com/presentation/d/1Qo0Nhlnmak6ecCzF_nhTStunc63frayP5RYA5bLD3TQ"
+ "slot_start": 1731472200000,
+ "slot_end": 1731474000000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1IOfjp_pKz83JTceKqk5Rve7U1YRQJSc4MA5OPmnj6oE"
},
"vector": [
0,
@@ -231593,11 +231111,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -231636,6 +231154,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -231767,7 +231286,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -232347,6 +231865,9 @@
0,
0,
0,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -232601,14 +232122,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -232904,6 +232418,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -232922,40 +232437,40 @@
},
{
"session": {
- "id": "developing-and-using-a-modular-folding-schemes-library",
- "sourceId": "PPFPQY",
- "title": "Developing and using a modular folding schemes library",
- "description": "We will present Sonobe, a modular folding-schemes library. It currently features implementations of Nova, CycleFold, Hypernova and ProtoGalaxy schemes and is compatible with a wide range of R1CS arithmetization libraries. we will briefly discuss what folding schemes are and how they fit into IVC-style proof systems. Next, we will explain how Sonobe was built and what features it supports. Finally, we will cover what has been built with Sonobe and how developers can start using it today.",
+ "id": "digital-pheromones-mpc-for-human-connection-and-coordination",
+ "sourceId": "LMCG3V",
+ "title": "Digital pheromones: MPC for human connection & coordination",
+ "description": "Recent MPC research from Cursive and PSE enables a new concept called \"digital pheromones\": the ability to produce lightweight, privacy-preserving signals that people can use to coordinate safely and efficiently.\r\n\r\nThe primary result we will cover is Trinity, a new 2PC scheme with nearly ideal UX/DevX, built on the trio of PLONK, Garbled Circuits, and KZG Witness Encryption. We will do a live demo with attendees and explore what a future filled with digital pheromones will enable!",
"track": "Applied Cryptography",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Folding schemes",
- "IVC",
- "Nova"
- ],
"tags": [
- "Libraries",
- "Zero-Knowledge",
- "Cryptography",
- "nova",
- "Cryptography",
- "Libraries",
- "Zero-Knowledge"
+ "MPC",
+ "Privacy",
+ "Use cases of cryptography"
],
+ "keywords": [],
+ "duration": 1517,
"language": "en",
- "speakers": [
- "pierre-daix-moreux",
- "arnaucube"
- ],
+ "sources_swarmHash": "1907282ffb309a0d8b977413439d8bf99c1a3372f0b59ab6607b011a0491ebce",
+ "sources_youtubeId": "TY2ZWmR_UqM",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731472200000,
- "slot_end": 1731474000000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1IOfjp_pKz83JTceKqk5Rve7U1YRQJSc4MA5OPmnj6oE"
+ "slot_start": 1731486000000,
+ "slot_end": 1731487800000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1VlzRulp0j62UZdPbUEc2y_6-IxSsimLBL_t3kn0xprA",
+ "resources_slides": null,
+ "speakers": [
+ "vivek-bhupatiraju"
+ ]
},
"vector": [
0,
@@ -233007,8 +232522,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -233222,9 +232735,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -233721,9 +233234,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
0,
0,
0,
@@ -233740,6 +233250,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -233800,6 +233311,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -233826,6 +233338,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -233979,7 +233492,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -234275,8 +233787,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -234293,49 +233805,41 @@
},
{
"session": {
- "id": "digital-pheromones-mpc-for-human-connection-and-coordination",
- "sourceId": "LMCG3V",
- "title": "Digital pheromones: MPC for human connection & coordination",
- "description": "Recent MPC research from Cursive and PSE enables a new concept called \"digital pheromones\": the ability to produce lightweight, privacy-preserving signals that people can use to coordinate safely and efficiently.\r\n\r\nThe primary result we will cover is Trinity, a new 2PC scheme with nearly ideal UX/DevX, built on the trio of PLONK, Garbled Circuits, and KZG Witness Encryption. We will do a live demo with attendees and explore what a future filled with digital pheromones will enable!",
- "track": "Applied Cryptography",
- "type": "Talk",
+ "id": "discovery-the-tool-at-the-core-of-l2beat",
+ "sourceId": "G9ESC7",
+ "title": "Discovery - the tool at the core of L2BEAT",
+ "description": "Hands on workshop about how to use an L2BEAT tool called discovery for mapping, researching and monitoring all the contracts involved in a project. We'll start by introducing the problem that discovery tries to solve and after that we'll get into trying to understand the architecture of a real world project by using the avenues this tool gives us. After this session the participant should feel empowered to use discovery to deepen his knowledge about all on-chain deployments.",
+ "track": "Developer Experience",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Developper",
"featured": false,
"doNotRecord": false,
+ "keywords": [
+ "Holistic monitoring",
+ "Architecture research"
+ ],
"tags": [
- "MPC",
- "Privacy",
- "Use cases of cryptography"
+ "Architecture",
+ "Tooling",
+ "DevEx",
+ "Event monitoring",
+ "research",
+ "DevEx",
+ "Event monitoring",
+ "Tooling"
],
- "keywords": [],
- "duration": 1517,
"language": "en",
- "sources_swarmHash": "1907282ffb309a0d8b977413439d8bf99c1a3372f0b59ab6607b011a0491ebce",
- "sources_youtubeId": "TY2ZWmR_UqM",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731486000000,
- "slot_end": 1731487800000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1VlzRulp0j62UZdPbUEc2y_6-IxSsimLBL_t3kn0xprA",
- "resources_slides": null,
"speakers": [
- "vivek-bhupatiraju"
- ]
+ "mateusz-radomski"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731638700000,
+ "slot_end": 1731645900000,
+ "slot_roomId": "classroom-c",
+ "resources_presentation": "https://docs.google.com/presentation/d/1T24SoFUkubwO-ppCiYWJoisNwayKtozmAgEJYNPvVho"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -234594,10 +234098,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -234605,6 +234105,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -235118,27 +234619,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -235197,24 +234678,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -235377,6 +234840,47 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -235642,7 +235146,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -235659,56 +235162,48 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
0
]
},
{
"session": {
- "id": "discovery-the-tool-at-the-core-of-l2beat",
- "sourceId": "G9ESC7",
- "title": "Discovery - the tool at the core of L2BEAT",
- "description": "Hands on workshop about how to use an L2BEAT tool called discovery for mapping, researching and monitoring all the contracts involved in a project. We'll start by introducing the problem that discovery tries to solve and after that we'll get into trying to understand the architecture of a real world project by using the avenues this tool gives us. After this session the participant should feel empowered to use discovery to deepen his knowledge about all on-chain deployments.",
- "track": "Developer Experience",
- "type": "Workshop",
- "expertise": "Intermediate",
- "audience": "Developper",
+ "id": "dj-and-after-party",
+ "sourceId": "Z8UXRG",
+ "title": "DJ and After Party",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Holistic monitoring",
- "Architecture research"
- ],
- "tags": [
- "Architecture",
- "Tooling",
- "DevEx",
- "Event monitoring",
- "research",
- "DevEx",
- "Event monitoring",
- "Tooling"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "mateusz-radomski"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731638700000,
- "slot_end": 1731645900000,
- "slot_roomId": "classroom-c",
- "resources_presentation": "https://docs.google.com/presentation/d/1T24SoFUkubwO-ppCiYWJoisNwayKtozmAgEJYNPvVho"
+ "slot_start": 1731668400000,
+ "slot_end": 1731675600000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1TSMgbtSJLOzOAEiyPEoXuekpCOjQiJ2mYcLOPgFaF3E"
},
"vector": [
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -235965,7 +235460,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -236472,7 +235966,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -236481,7 +235974,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -236513,7 +236005,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -236703,7 +236194,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -236721,7 +236211,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -237012,10 +236501,13 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 2,
0,
0,
0,
@@ -237024,7 +236516,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -237034,9 +236525,9 @@
},
{
"session": {
- "id": "dj-and-after-party",
- "sourceId": "Z8UXRG",
- "title": "DJ and After Party",
+ "id": "dj-anderson",
+ "sourceId": "V393ZX",
+ "title": "DJ Anderson",
"description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
"track": "Entertainment",
"type": "Music",
@@ -237049,10 +236540,10 @@
"language": "en",
"speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731668400000,
- "slot_end": 1731675600000,
+ "slot_start": 1731567600000,
+ "slot_end": 1731571200000,
"slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1TSMgbtSJLOzOAEiyPEoXuekpCOjQiJ2mYcLOPgFaF3E"
+ "resources_presentation": "https://docs.google.com/presentation/d/11UdQ5iBzKBx_FS4T0nj0XPX9C1X0bSm-aP2bwq7jrOI"
},
"vector": [
0,
@@ -238366,9 +237857,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -238390,9 +237878,9 @@
},
{
"session": {
- "id": "dj-anderson",
- "sourceId": "V393ZX",
- "title": "DJ Anderson",
+ "id": "dj-i34r7h",
+ "sourceId": "QTHGFE",
+ "title": "DJ @i34r7h",
"description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
"track": "Entertainment",
"type": "Music",
@@ -238405,10 +237893,10 @@
"language": "en",
"speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731567600000,
- "slot_end": 1731571200000,
+ "slot_start": 1731639600000,
+ "slot_end": 1731643200000,
"slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/11UdQ5iBzKBx_FS4T0nj0XPX9C1X0bSm-aP2bwq7jrOI"
+ "resources_presentation": "https://docs.google.com/presentation/d/1f64FrhWEvOeHjw8XlNFarHOwwNkBaofQKZdOavm-Zq4"
},
"vector": [
0,
@@ -239722,9 +239210,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -239746,9 +239231,9 @@
},
{
"session": {
- "id": "dj-i34r7h",
- "sourceId": "QTHGFE",
- "title": "DJ @i34r7h",
+ "id": "dj-mayu",
+ "sourceId": "XV779L",
+ "title": "DJ MAYU",
"description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
"track": "Entertainment",
"type": "Music",
@@ -239761,10 +239246,10 @@
"language": "en",
"speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731639600000,
- "slot_end": 1731643200000,
+ "slot_start": 1731646800000,
+ "slot_end": 1731650400000,
"slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1f64FrhWEvOeHjw8XlNFarHOwwNkBaofQKZdOavm-Zq4"
+ "resources_presentation": "https://docs.google.com/presentation/d/1t2zQdmj0AJUDWbkdwI8GyR90vs3nQ_7TKvydOwUZYYk"
},
"vector": [
0,
@@ -241078,9 +240563,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -241102,25 +240584,27 @@
},
{
"session": {
- "id": "dj-mayu",
- "sourceId": "XV779L",
- "title": "DJ MAYU",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "id": "djing-pino7",
+ "sourceId": "SPWJHX",
+ "title": "DJing - pino7",
+ "description": "I am a builder and a volunteer in Devcon SEA. Back in the days I've decided that I wanted to become awesome, and here I am in my journey. I am UX/UI Designer and I am becoming a React Developer. I have always being passionate about music. And there's always space for it during my life journey. I love communities, people, organizing events and playing some good music.",
"track": "Entertainment",
"type": "Music",
- "expertise": "",
- "audience": "Engineering",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [],
"tags": [],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "pino7"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731646800000,
- "slot_end": 1731650400000,
+ "slot_start": 1731564000000,
+ "slot_end": 1731567600000,
"slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1t2zQdmj0AJUDWbkdwI8GyR90vs3nQ_7TKvydOwUZYYk"
+ "resources_presentation": "https://docs.google.com/presentation/d/1FZiG2A1-zzZBVPF6IvnlZPydiJX9JFyp4ngPzFzJTEo"
},
"vector": [
0,
@@ -241389,11 +240873,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 6,
0,
0,
0,
@@ -242440,13 +241920,14 @@
2,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -242458,27 +241939,54 @@
},
{
"session": {
- "id": "djing-pino7",
- "sourceId": "SPWJHX",
- "title": "DJing - pino7",
- "description": "I am a builder and a volunteer in Devcon SEA. Back in the days I've decided that I wanted to become awesome, and here I am in my journey. I am UX/UI Designer and I am becoming a React Developer. I have always being passionate about music. And there's always space for it during my life journey. I love communities, people, organizing events and playing some good music.",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "Intermediate",
- "audience": "Community",
+ "id": "do-you-really-know-your-web3-users",
+ "sourceId": "YRDFDY",
+ "title": "Do you really know your web3 users?",
+ "description": "Product discovery is to understand users' problems and using that knowledge to build a product. In the world of Web3, where anonymity & privacy prevail, how can teams identify user segments & collect relevant data to understand behaviours behind accounts? As we aim to onboard the next billion web3 users, how should we approach activation & growth, considering best practices and emerging trends? This panel will explore strategies for effective product discovery in a privacy-centric ecosystem.",
+ "track": "Usability",
+ "type": "Panel",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
- "language": "en",
- "speakers": [
- "pino7"
+ "tags": [
+ "Product-market fit",
+ "User Experience",
+ "UI/UX",
+ "User Research",
+ "product",
+ "discovery",
+ "Product-market fit",
+ "UI/UX",
+ "User Experience",
+ "User Research"
+ ],
+ "keywords": [
+ "Product Management",
+ "Strategy",
+ "Product Discovery"
],
+ "duration": 3425,
+ "language": "en",
+ "sources_swarmHash": "ae5d589708b7deb49fa418329e2b03c6b8b14d698f9e4c29bd4e4a97b2b285b0",
+ "sources_youtubeId": "L44ymSShmKM",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731564000000,
- "slot_end": 1731567600000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1FZiG2A1-zzZBVPF6IvnlZPydiJX9JFyp4ngPzFzJTEo"
+ "slot_start": 1731394800000,
+ "slot_end": 1731398400000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1NT9-QOOV4dbn06g_FMOVREI8em-zEVjMVNnJ2DBkCuc",
+ "resources_slides": null,
+ "speakers": [
+ "rahul-rumalla",
+ "alice-chaverot",
+ "austin-keeble",
+ "romina-bungert"
+ ]
},
"vector": [
0,
@@ -242489,7 +241997,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -242748,17 +242255,11 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
+ 6,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -243253,6 +242754,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -243294,6 +242796,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -243321,6 +242825,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -243503,6 +243008,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -243800,9 +243307,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -243811,61 +243315,46 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "do-you-really-know-your-web3-users",
- "sourceId": "YRDFDY",
- "title": "Do you really know your web3 users?",
- "description": "Product discovery is to understand users' problems and using that knowledge to build a product. In the world of Web3, where anonymity & privacy prevail, how can teams identify user segments & collect relevant data to understand behaviours behind accounts? As we aim to onboard the next billion web3 users, how should we approach activation & growth, considering best practices and emerging trends? This panel will explore strategies for effective product discovery in a privacy-centric ecosystem.",
- "track": "Usability",
- "type": "Panel",
- "expertise": "Beginner",
- "audience": "Product",
+ "id": "does-ethereum-really-need-pbs-solving-mev-at-the-app-vs-the-infrastructure-layer",
+ "sourceId": "TNKFPP",
+ "title": "Does Ethereum Really Need PBS? Solving MEV at the app vs the infrastructure layer",
+ "description": "In this talk, we will give a brief history of MEV (Maximal Extractable Value) and its influence on enshrining PBS (Proposer Builder Separation) into Ethereum. We will explore the Ethereum community’s evolving perspectives on PBS while looking at successful outcomes, unexpected consequences, and alternate solutions. \r\n\r\nUltimately, the talk will provocatively ask: does Ethereum really need PBS at all?",
+ "track": "Cryptoeconomics",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Product-market fit",
- "User Experience",
- "UI/UX",
- "User Research",
- "product",
- "discovery",
- "Product-market fit",
- "UI/UX",
- "User Experience",
- "User Research"
- ],
"keywords": [
- "Product Management",
- "Strategy",
- "Product Discovery"
+ "Intents",
+ "MEV",
+ "PBS",
+ "Redistribution"
+ ],
+ "tags": [
+ "redistribution"
],
- "duration": 3425,
"language": "en",
- "sources_swarmHash": "ae5d589708b7deb49fa418329e2b03c6b8b14d698f9e4c29bd4e4a97b2b285b0",
- "sources_youtubeId": "L44ymSShmKM",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
+ "speakers": [
+ "felix-leupold"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731394800000,
- "slot_end": 1731398400000,
+ "slot_start": 1731639900000,
+ "slot_end": 1731640500000,
"slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1NT9-QOOV4dbn06g_FMOVREI8em-zEVjMVNnJ2DBkCuc",
- "resources_slides": null,
- "speakers": [
- "rahul-rumalla",
- "alice-chaverot",
- "austin-keeble",
- "romina-bungert"
- ]
+ "resources_presentation": "https://docs.google.com/presentation/d/1y6tAISW_K9exOHiT-8JDt3qSFgyDYP0v5Zkc3T7JIdw"
},
"vector": [
+ 0,
+ 0,
+ 6,
+ 0,
0,
0,
0,
@@ -243874,7 +243363,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -244134,9 +243622,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
6,
0,
0,
@@ -244634,7 +244119,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -244676,8 +244160,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -244705,7 +244187,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -244889,10 +244370,9 @@
0,
0,
0,
- 2,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -245185,9 +244665,11 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
0,
0,
- 2,
0,
0,
0,
@@ -245201,38 +244683,40 @@
},
{
"session": {
- "id": "does-ethereum-really-need-pbs-solving-mev-at-the-app-vs-the-infrastructure-layer",
- "sourceId": "TNKFPP",
- "title": "Does Ethereum Really Need PBS? Solving MEV at the app vs the infrastructure layer",
- "description": "In this talk, we will give a brief history of MEV (Maximal Extractable Value) and its influence on enshrining PBS (Proposer Builder Separation) into Ethereum. We will explore the Ethereum community’s evolving perspectives on PBS while looking at successful outcomes, unexpected consequences, and alternate solutions. \r\n\r\nUltimately, the talk will provocatively ask: does Ethereum really need PBS at all?",
- "track": "Cryptoeconomics",
- "type": "Lightning Talk",
+ "id": "dont-get-rekt-practical-threat-detection-for-users-and-devs",
+ "sourceId": "Y7QGNQ",
+ "title": "Don’t get rekt: practical threat detection for users and devs",
+ "description": "Learn to uncover, and protect against, weaponized repositories, sites and tools targeting web3 users, devs & researchers. With examples and hands-on exercises, the session begins with topics like detecting suspicious activity in sites, handling wallet secrets & signatures, decoding calldata of malicious txs, and simulating them to avoid attacks. To then cover more advanced techniques to spot harmful backdoors in code repositories and services that can impact on devs & users’ safety.",
+ "track": "Security",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developer",
"featured": false,
- "doNotRecord": false,
+ "doNotRecord": true,
"keywords": [
- "Intents",
- "MEV",
- "PBS",
- "Redistribution"
+ "user safety",
+ "developer safety",
+ "phishing"
],
"tags": [
- "redistribution"
+ "Tooling",
+ "Security",
+ "phishing",
+ "Security",
+ "Tooling"
],
"language": "en",
"speakers": [
- "felix-leupold"
+ "tincho",
+ "matta-the-red-guild"
],
"eventId": "devcon-7",
- "slot_start": 1731639900000,
- "slot_end": 1731640500000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1y6tAISW_K9exOHiT-8JDt3qSFgyDYP0v5Zkc3T7JIdw"
+ "slot_start": 1731488400000,
+ "slot_end": 1731495600000,
+ "slot_roomId": "classroom-b",
+ "resources_presentation": "https://docs.google.com/presentation/d/1iQKRk0GBHlEdWgzH2yQxE2MJqGiiPO9fQI4PkTbLKOk"
},
"vector": [
- 0,
- 0,
6,
0,
0,
@@ -245503,13 +244987,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -245985,6 +245466,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -246005,6 +245487,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -246548,9 +246031,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -246566,38 +246049,38 @@
},
{
"session": {
- "id": "dont-get-rekt-practical-threat-detection-for-users-and-devs",
- "sourceId": "Y7QGNQ",
- "title": "Don’t get rekt: practical threat detection for users and devs",
- "description": "Learn to uncover, and protect against, weaponized repositories, sites and tools targeting web3 users, devs & researchers. With examples and hands-on exercises, the session begins with topics like detecting suspicious activity in sites, handling wallet secrets & signatures, decoding calldata of malicious txs, and simulating them to avoid attacks. To then cover more advanced techniques to spot harmful backdoors in code repositories and services that can impact on devs & users’ safety.",
+ "id": "double-entry-point-issues-from-breaking-compound-to-uniswap-v4",
+ "sourceId": "N9ZSQW",
+ "title": "Double entry point issues - From breaking Compound to Uniswap v4",
+ "description": "A short explanation of a critical-severity vulnerability we found in the Uniswap V4 core contracts that would have caused a ~$15M loss in Uniswap's pools. The goal is to explain the risks of double entry points, from the $30M+ TUSD issue in Compound to the Uniswap V4-specific case where protocols use native tokens and operate on chains where the native token has a corresponding ERC-20 token, and how to prevent them.",
"track": "Security",
- "type": "Workshop",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Research",
"featured": false,
- "doNotRecord": true,
+ "doNotRecord": false,
"keywords": [
- "user safety",
- "developer safety",
- "phishing"
+ "Contest"
],
"tags": [
- "Tooling",
- "Security",
- "phishing",
"Security",
- "Tooling"
+ "Bug",
+ "Bounties",
+ "contest",
+ "Architecture",
+ "Auditing",
+ "Bug",
+ "Security"
],
"language": "en",
"speakers": [
- "tincho",
- "matta-the-red-guild"
+ "jota-carpanelli"
],
"eventId": "devcon-7",
- "slot_start": 1731488400000,
- "slot_end": 1731495600000,
- "slot_roomId": "classroom-b",
- "resources_presentation": "https://docs.google.com/presentation/d/1iQKRk0GBHlEdWgzH2yQxE2MJqGiiPO9fQI4PkTbLKOk"
+ "slot_start": 1731657000000,
+ "slot_end": 1731657600000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1nsS3htMgQANlE-F_Bcm9jAbdeixMwbjLd0u9GrwuCV0"
},
"vector": [
6,
@@ -246873,11 +246356,8 @@
0,
0,
0,
- 6,
- 6,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -247373,9 +246853,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -247417,6 +246894,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -247506,6 +246984,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -247610,6 +247089,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -247627,7 +247107,7 @@
0,
0,
2,
- 0,
+ 2,
0,
0,
0,
@@ -247918,7 +247398,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -247930,52 +247409,52 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "double-entry-point-issues-from-breaking-compound-to-uniswap-v4",
- "sourceId": "N9ZSQW",
- "title": "Double entry point issues - From breaking Compound to Uniswap v4",
- "description": "A short explanation of a critical-severity vulnerability we found in the Uniswap V4 core contracts that would have caused a ~$15M loss in Uniswap's pools. The goal is to explain the risks of double entry points, from the $30M+ TUSD issue in Compound to the Uniswap V4-specific case where protocols use native tokens and operate on chains where the native token has a corresponding ERC-20 token, and how to prevent them.",
- "track": "Security",
+ "id": "downtown-stimulus-public-goods-funding-for-main-st",
+ "sourceId": "VC9TDM",
+ "title": "Downtown Stimulus: Public Goods Funding for Main St",
+ "description": "Web3 Public Goods Funding has left web3, & successfully hit main st! 💰🏦\r\n\r\nThe downtown stimulus team raised $43k for Boulder Colorado COVID economic recovery & proved QF works in mainstream USA. Learn about this experiment & lessons from it from Gitcoin founder Kevin Owocki.",
+ "track": "Real World Ethereum",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Contest"
+ "mainstream"
],
"tags": [
- "Security",
- "Bug",
- "Bounties",
- "contest",
- "Architecture",
- "Auditing",
- "Bug",
- "Security"
+ "Quadratic Voting",
+ "Public good",
+ "Local Impact",
+ "UI/UX",
+ "mainstream",
+ "Public good",
+ "UI/UX"
],
"language": "en",
"speakers": [
- "jota-carpanelli"
+ "kevin-owocki"
],
"eventId": "devcon-7",
- "slot_start": 1731657000000,
- "slot_end": 1731657600000,
+ "slot_start": 1731581400000,
+ "slot_end": 1731582000000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1nsS3htMgQANlE-F_Bcm9jAbdeixMwbjLd0u9GrwuCV0"
+ "resources_presentation": "https://docs.google.com/presentation/d/1Lf82ct08SpegO30t849kscAqeyNa8bTNVpMQ8ljElfA"
},
"vector": [
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -248721,7 +248200,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -248778,12 +248256,13 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -248827,6 +248306,9 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
0,
0,
0,
@@ -248873,7 +248355,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -248925,6 +248406,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -248954,6 +248439,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -248979,24 +248468,11 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
0,
- 0,
- 0,
- 0,
- 2,
2,
0,
0,
@@ -249282,16 +248758,16 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -249304,37 +248780,39 @@
},
{
"session": {
- "id": "downtown-stimulus-public-goods-funding-for-main-st",
- "sourceId": "VC9TDM",
- "title": "Downtown Stimulus: Public Goods Funding for Main St",
- "description": "Web3 Public Goods Funding has left web3, & successfully hit main st! 💰🏦\r\n\r\nThe downtown stimulus team raised $43k for Boulder Colorado COVID economic recovery & proved QF works in mainstream USA. Learn about this experiment & lessons from it from Gitcoin founder Kevin Owocki.",
+ "id": "ebay-and-web3-powered-digital-product-passports-and-what-this-could-mean-for-the-future-of-commerce",
+ "sourceId": "DWMA3P",
+ "title": "eBay & web3 powered Digital Product Passports and what this could mean for the future of commerce?",
+ "description": "eBay is embracing web3 technologies to fulfil the vision of a truly connected product world. Digital Product Passports (DPPs) underpin this movement with a real world application of public blockchain technologies, tokenised products, attestation based technologies and selective disclosure schemes as the technology of choice.\r\n\r\nI will explore what this could mean for one of the world of ecommerce, why brands are embracing this movement and whats in it for the consumer.",
"track": "Real World Ethereum",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
"keywords": [
- "mainstream"
+ "digital-product-passports",
+ "DPPs",
+ "luxury"
],
"tags": [
- "Quadratic Voting",
- "Public good",
- "Local Impact",
- "UI/UX",
- "mainstream",
- "Public good",
- "UI/UX"
+ "Digital Sovereignty",
+ "Use Cases",
+ "Regulation",
+ "luxury",
+ "Digital Sovereignty",
+ "Regulation",
+ "Use Cases"
],
"language": "en",
"speakers": [
- "kevin-owocki"
+ "james-morgan"
],
"eventId": "devcon-7",
- "slot_start": 1731581400000,
- "slot_end": 1731582000000,
+ "slot_start": 1731567600000,
+ "slot_end": 1731568200000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Lf82ct08SpegO30t849kscAqeyNa8bTNVpMQ8ljElfA"
+ "resources_presentation": "https://docs.google.com/presentation/d/1oolmmoeS_8L3O435iq2vuXQPr9H_eWlvs-2T3XokFwU"
},
"vector": [
0,
@@ -250136,6 +249614,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -250148,9 +249627,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -250167,6 +249643,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -250194,11 +249671,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -250298,7 +249775,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -250332,7 +249808,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -250658,7 +250133,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -250667,44 +250141,56 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "ebay-and-web3-powered-digital-product-passports-and-what-this-could-mean-for-the-future-of-commerce",
- "sourceId": "DWMA3P",
- "title": "eBay & web3 powered Digital Product Passports and what this could mean for the future of commerce?",
- "description": "eBay is embracing web3 technologies to fulfil the vision of a truly connected product world. Digital Product Passports (DPPs) underpin this movement with a real world application of public blockchain technologies, tokenised products, attestation based technologies and selective disclosure schemes as the technology of choice.\r\n\r\nI will explore what this could mean for one of the world of ecommerce, why brands are embracing this movement and whats in it for the consumer.",
- "track": "Real World Ethereum",
+ "id": "ecosystem-development-best-practices-and-why-we-need-to-start-with-builders-first",
+ "sourceId": "EY3HL9",
+ "title": "Ecosystem Development Best Practices, and why we need to start with builders first",
+ "description": "Given the myriad of chains out there, it is increasingly crucial for L2s to solidify their ecosystem building playbook and constantly refine it to win over (and more importantly, retain) users and builders. As an ecosystem builder in SEA (Thailand) who has worked with over 10 ecosystems including other L1s, on local, regional and global initiatives, I am excited to share the ins and outs of ecosystem building from a neutral perspective.",
+ "track": "Layer 2",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Product",
+ "audience": "Business",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "digital-product-passports",
- "DPPs",
- "luxury"
- ],
"tags": [
- "Digital Sovereignty",
- "Use Cases",
- "Regulation",
- "luxury",
- "Digital Sovereignty",
- "Regulation",
- "Use Cases"
+ "Layer 2s",
+ "DevRel",
+ "Best Practices",
+ "management",
+ "stakeholder",
+ "Best Practices",
+ "DevRel",
+ "Layer 2s"
],
- "language": "en",
- "speakers": [
- "james-morgan"
+ "keywords": [
+ "Ecosystem Building",
+ "Ecosystem Design",
+ "Developer Experience",
+ "Stakeholder Management"
],
+ "duration": 407,
+ "language": "en",
+ "sources_swarmHash": "3ca335e97a65bd21e260157bab87ec0fc8fb8c50e77214212c844d794eb17896",
+ "sources_youtubeId": "xqs8trszoOY",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67331cf83a168eb5353a19d3.vtt",
+ "transcript_text": " Hi, good afternoon, guys. So my name is Ngan. I'm the co-founder of Symmetry. I'm also a fellow Thai here. So it's a pleasure for us to welcome you to my home country and my hometown, which is Bangkok. So really excited to be here. So yeah, straight into my talk. So as you can see from the talk title, it's about ecosystem development. So what I do at Symmetry is basically we help change on what more builders and users from Thailand. So I figured this would be a good topic to touch on given DEF CON so what exactly is ecosystem building so ecosystem building is basically a to the marketplace right so side marketplace so when you're building chains you need both barriers and users and you did both at we strategic timings a chain cannot function with one or another",
"eventId": "devcon-7",
- "slot_start": 1731567600000,
- "slot_end": 1731568200000,
+ "slot_start": 1731402000000,
+ "slot_end": 1731402600000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1oolmmoeS_8L3O435iq2vuXQPr9H_eWlvs-2T3XokFwU"
+ "resources_presentation": "https://docs.google.com/presentation/d/12auC9dhscSkSUtYU1CqtRqHz64-ljDXc1f7otM8hLMw",
+ "resources_slides": null,
+ "speakers": [
+ "nine-arnakorn"
+ ]
},
"vector": [
0,
@@ -250713,8 +250199,8 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -251487,6 +250973,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -251509,10 +250996,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -251525,6 +251008,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -251538,7 +251022,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -251566,7 +251049,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -251634,6 +251116,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -251738,7 +251221,7 @@
0,
0,
2,
- 0,
+ 2,
0,
0,
0,
@@ -252027,7 +251510,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -252037,54 +251519,53 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "ecosystem-development-best-practices-and-why-we-need-to-start-with-builders-first",
- "sourceId": "EY3HL9",
- "title": "Ecosystem Development Best Practices, and why we need to start with builders first",
- "description": "Given the myriad of chains out there, it is increasingly crucial for L2s to solidify their ecosystem building playbook and constantly refine it to win over (and more importantly, retain) users and builders. As an ecosystem builder in SEA (Thailand) who has worked with over 10 ecosystems including other L1s, on local, regional and global initiatives, I am excited to share the ins and outs of ecosystem building from a neutral perspective.",
- "track": "Layer 2",
+ "id": "eea-and-the-institutional-infinity-garden",
+ "sourceId": "JQBXXD",
+ "title": "EEA and the Institutional Infinity Garden",
+ "description": "This talk would be to give an overview on the latest from the Enterprise Ethereum Alliance, how the year has progressed in enterprise and how EEA seeks to support and guide institutions to participate in Ethereum's Infinity Garden.",
+ "track": "Real World Ethereum",
"type": "Lightning Talk",
"expertise": "Beginner",
"audience": "Business",
"featured": false,
"doNotRecord": false,
"tags": [
- "Layer 2s",
- "DevRel",
- "Best Practices",
- "management",
- "stakeholder",
- "Best Practices",
- "DevRel",
- "Layer 2s"
+ "Coordination",
+ "Vision",
+ "Use Cases",
+ "institutional",
+ "Coordination",
+ "Use Cases",
+ "Vision"
],
"keywords": [
- "Ecosystem Building",
- "Ecosystem Design",
- "Developer Experience",
- "Stakeholder Management"
+ "Business",
+ "Enterprise",
+ "Instituional"
],
- "duration": 407,
+ "duration": 602,
"language": "en",
- "sources_swarmHash": "3ca335e97a65bd21e260157bab87ec0fc8fb8c50e77214212c844d794eb17896",
- "sources_youtubeId": "xqs8trszoOY",
+ "sources_swarmHash": "627a8020ea8fffe7e60da9ea41e68e2239bf60b5384058c21bd9da1f40eec92e",
+ "sources_youtubeId": "dYgucH3a7sI",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67331cf83a168eb5353a19d3.vtt",
- "transcript_text": " Hi, good afternoon, guys. So my name is Ngan. I'm the co-founder of Symmetry. I'm also a fellow Thai here. So it's a pleasure for us to welcome you to my home country and my hometown, which is Bangkok. So really excited to be here. So yeah, straight into my talk. So as you can see from the talk title, it's about ecosystem development. So what I do at Symmetry is basically we help change on what more builders and users from Thailand. So I figured this would be a good topic to touch on given DEF CON so what exactly is ecosystem building so ecosystem building is basically a to the marketplace right so side marketplace so when you're building chains you need both barriers and users and you did both at we strategic timings a chain cannot function with one or another",
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731402000000,
- "slot_end": 1731402600000,
+ "slot_start": 1731480000000,
+ "slot_end": 1731480600000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/12auC9dhscSkSUtYU1CqtRqHz64-ljDXc1f7otM8hLMw",
+ "resources_presentation": "https://docs.google.com/presentation/d/1f1uiHRqQIfhY0F3DmSPJ-wpu3lCdP00YCID-a2-UblQ",
"resources_slides": null,
"speakers": [
- "nine-arnakorn"
+ "karen-scarbrough"
]
},
"vector": [
@@ -252094,7 +251575,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -252366,6 +251846,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -252871,7 +252352,17 @@
0,
0,
0,
- 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -252982,6 +252473,52 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -253061,6 +252598,15 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -253119,8 +252665,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -253337,10 +252881,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -253350,6 +252896,48 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "efficient-non-native-snark-recursion-using-bivariate-polynomial-testing",
+ "sourceId": "E8KYKE",
+ "title": "Efficient non-native SNARK recursion using bivariate polynomial testing",
+ "description": "Efficient SNARK recursion requires switching between pairing friendly elliptic curves. In most optimal approaches these curves would construct a cycle, but there are no such known cycles. Instead, we use non-native arithmetic to brute force the pairing computation at the cycle cut-off.\r\nWe describe an approach for combining direct field extension with polynomial-based non-native arithmetic. This reduces pairing computation to bivariate polynomial identity testing using Schwartz-Zippel lemma.",
+ "track": "Applied Cryptography",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "Pairing",
+ "based",
+ "ZK"
+ ],
+ "tags": [
+ "ZKP",
+ "Cryptography",
+ "SNARK",
+ "zk",
+ "based",
+ "pairing",
+ "Cryptography",
+ "SNARK",
+ "ZKP"
+ ],
+ "language": "en",
+ "speakers": [
+ "ivo-kubjas"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731474000000,
+ "slot_end": 1731475800000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1uBrjsIa4svOJ9BePcS4YgEcFXFjVxeeeS9RBVSKBwzw"
+ },
+ "vector": [
0,
0,
0,
@@ -253360,6 +252948,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -253403,12 +252992,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -253418,62 +253005,12 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "eea-and-the-institutional-infinity-garden",
- "sourceId": "JQBXXD",
- "title": "EEA and the Institutional Infinity Garden",
- "description": "This talk would be to give an overview on the latest from the Enterprise Ethereum Alliance, how the year has progressed in enterprise and how EEA seeks to support and guide institutions to participate in Ethereum's Infinity Garden.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Business",
- "featured": false,
- "doNotRecord": false,
- "tags": [
- "Coordination",
- "Vision",
- "Use Cases",
- "institutional",
- "Coordination",
- "Use Cases",
- "Vision"
- ],
- "keywords": [
- "Business",
- "Enterprise",
- "Instituional"
- ],
- "duration": 602,
- "language": "en",
- "sources_swarmHash": "627a8020ea8fffe7e60da9ea41e68e2239bf60b5384058c21bd9da1f40eec92e",
- "sources_youtubeId": "dYgucH3a7sI",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731480000000,
- "slot_end": 1731480600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1f1uiHRqQIfhY0F3DmSPJ-wpu3lCdP00YCID-a2-UblQ",
- "resources_slides": null,
- "speakers": [
- "karen-scarbrough"
- ]
- },
- "vector": [
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -253680,6 +253217,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -253746,7 +253284,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -254163,6 +253700,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -254194,6 +253732,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -254223,6 +253762,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -254298,7 +253838,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -254374,7 +253913,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -254430,6 +253968,9 @@
0,
0,
0,
+ 2,
+ 2,
+ 2,
0,
0,
0,
@@ -254453,7 +253994,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -254500,7 +254040,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -254709,9 +254248,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -254724,10 +254265,57 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "eip-7251-maximum-effective-balance-overview",
+ "sourceId": "BBFNLG",
+ "title": "EIP-7251 - Maximum effective balance overview",
+ "description": "An overview of the maximum effective balance change coming in Electra.\r\nAt a high level, other considerations that were required to allow the maximum effective balance increase in Electra, and ensure that it delivers value.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Stakers/Validators",
+ "featured": false,
+ "doNotRecord": false,
+ "tags": [
+ "Core Protocol",
+ "Staking",
+ "Pectra",
+ "Core Protocol",
+ "Staking"
+ ],
+ "keywords": [
+ "Pectra"
+ ],
+ "duration": 1218,
+ "language": "en",
+ "sources_swarmHash": "7232962eceb9c9b07027a3ebb1759835c57a4c1aacf89e245dbceaca4a6ae4dc",
+ "sources_youtubeId": "EwW6dNi9VCY",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733027280d989c5b7bd3263.vtt",
+ "transcript_text": " Hi everyone. Jeez, these lights are bright. I'm here today to talk to you about increasing the maximum effective balance, EIP 7251. It's less of a technical talk than the previous one, because I think there's a few things we probably need to go over.",
+ "eventId": "devcon-7",
+ "slot_start": 1731394800000,
+ "slot_end": 1731396600000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Q5srMGhMm8grwI_O0CFKN_QN1QRx24-AxIwgbDha6U0",
+ "resources_slides": null,
+ "speakers": [
+ "paul-harris"
+ ]
+ },
+ "vector": [
0,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -254782,12 +254370,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -254797,48 +254383,6 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "efficient-non-native-snark-recursion-using-bivariate-polynomial-testing",
- "sourceId": "E8KYKE",
- "title": "Efficient non-native SNARK recursion using bivariate polynomial testing",
- "description": "Efficient SNARK recursion requires switching between pairing friendly elliptic curves. In most optimal approaches these curves would construct a cycle, but there are no such known cycles. Instead, we use non-native arithmetic to brute force the pairing computation at the cycle cut-off.\r\nWe describe an approach for combining direct field extension with polynomial-based non-native arithmetic. This reduces pairing computation to bivariate polynomial identity testing using Schwartz-Zippel lemma.",
- "track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Pairing",
- "based",
- "ZK"
- ],
- "tags": [
- "ZKP",
- "Cryptography",
- "SNARK",
- "zk",
- "based",
- "pairing",
- "Cryptography",
- "SNARK",
- "ZKP"
- ],
- "language": "en",
- "speakers": [
- "ivo-kubjas"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731474000000,
- "slot_end": 1731475800000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1uBrjsIa4svOJ9BePcS4YgEcFXFjVxeeeS9RBVSKBwzw"
- },
- "vector": [
0,
0,
0,
@@ -254849,7 +254393,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -255047,6 +254590,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -255119,7 +254663,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -255535,6 +255078,16 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -255604,7 +255157,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -255666,7 +255218,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -255792,6 +255343,44 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -255873,9 +255462,6 @@
0,
0,
0,
- 2,
- 2,
- 2,
0,
0,
0,
@@ -256034,6 +255620,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -256043,16 +255630,63 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "eip-7702-a-technical-deep-dive",
+ "sourceId": "NNNPLC",
+ "title": "EIP-7702: a technical deep dive",
+ "description": "We'll discuss some of the design goals that lead to EIP-7702, how it works, and what will be possible for users after the Pectra network upgrade.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "tags": [
+ "Core Protocol",
+ "Account Abstraction",
+ "eip",
+ "Account Abstraction",
+ "Core Protocol"
+ ],
+ "keywords": [
+ "EIP"
+ ],
+ "duration": 1299,
+ "language": "en",
+ "sources_swarmHash": "d4c1051f49830760c82a47ec5d0413b0d5fef571e4c09d5a7a0c76f69753c619",
+ "sources_youtubeId": "_k5fKlKBWV4",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
+ "eventId": "devcon-7",
+ "slot_start": 1731393000000,
+ "slot_end": 1731394800000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/15huammnvrT8ljoiAi9Bnn4jcV_r6L0sm3_gBK-LqQ-4",
+ "resources_slides": null,
+ "speakers": [
+ "lightclient"
+ ]
+ },
+ "vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -256152,11 +255786,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -256166,60 +255798,10 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0
- ]
- },
- {
- "session": {
- "id": "eip-7251-maximum-effective-balance-overview",
- "sourceId": "BBFNLG",
- "title": "EIP-7251 - Maximum effective balance overview",
- "description": "An overview of the maximum effective balance change coming in Electra.\r\nAt a high level, other considerations that were required to allow the maximum effective balance increase in Electra, and ensure that it delivers value.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Stakers/Validators",
- "featured": false,
- "doNotRecord": false,
- "tags": [
- "Core Protocol",
- "Staking",
- "Pectra",
- "Core Protocol",
- "Staking"
- ],
- "keywords": [
- "Pectra"
- ],
- "duration": 1218,
- "language": "en",
- "sources_swarmHash": "7232962eceb9c9b07027a3ebb1759835c57a4c1aacf89e245dbceaca4a6ae4dc",
- "sources_youtubeId": "EwW6dNi9VCY",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733027280d989c5b7bd3263.vtt",
- "transcript_text": " Hi everyone. Jeez, these lights are bright. I'm here today to talk to you about increasing the maximum effective balance, EIP 7251. It's less of a technical talk than the previous one, because I think there's a few things we probably need to go over.",
- "eventId": "devcon-7",
- "slot_start": 1731394800000,
- "slot_end": 1731396600000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1Q5srMGhMm8grwI_O0CFKN_QN1QRx24-AxIwgbDha6U0",
- "resources_slides": null,
- "speakers": [
- "paul-harris"
- ]
- },
- "vector": [
0,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -256263,6 +255845,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -256495,7 +256078,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -256868,6 +256450,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -256899,6 +256482,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -256985,7 +256569,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -257095,7 +256678,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -257134,6 +256716,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -257251,7 +256834,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -257413,6 +256995,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -257425,6 +257009,52 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "eip-7732-enshrined-proposer-builder-separation",
+ "sourceId": "TKBF9R",
+ "title": "[EIP-7732] enshrined Proposer Builder Separation",
+ "description": "ePBS implementation in Prysm and Nimbus, fundamentally aimed at solving about solving trust issues. We're gonna discuss the block-auction, slot-auction and the approach proposed by Francesco during the cohort. Some technical challenges and problems that we came across like separating EL and CL block, PTC committee etc.",
+ "track": "[CLS] EPF Day",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "tags": [
+ "Censorship Resistance",
+ "Consensus",
+ "Core Protocol",
+ "PBS"
+ ],
+ "keywords": [
+ "ePBS",
+ "EIP-7732"
+ ],
+ "duration": 751,
+ "language": "en",
+ "sources_swarmHash": "e326ff4a5c85f7cfdcbb4ccebbd229632df88de258c3b4daa59aac0bad48ad30",
+ "sources_youtubeId": "P2DkizLb79w",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734486c9dbb7a90e1866fa0.vtt",
+ "transcript_text": " Hi, good afternoon everyone. So my name is Caleb. I've been working on the PBS implementation in the Nimbus consensus clients. So coming into EPF, the motivation for me initially was choosing a project that touched on almost every major part of the consensus client because I wanted to have a deeper understanding of the protocol in itself. So I decided to choose EIP-7732 and try and propose a builder separation. It was proposed to be implemented in Nimbus. I've been praising it initially, but there was a need for client diversity and to have it implemented in Nimbus, I mean, Prism initially, but there was need for client diversity and to have it implemented in multiple clients. So basically what the AIP does is basically separating the Ethereum block into a consensus and execution, into the consensus and execution parts basically. So it adds a mechanism for the proposer to be able to choose a builder on chain or on protocol, which is currently done off protocol. So it fundamentally changes the way a block is validated by decoupling the execution validation from the consensus validation. So currently, beacon block proposers, they request the hash tree route from a third-party builder via a relay. They submit a signed blinded Beacon Block to that trusted relay. The relay is responsible for replacing that hash tree route with the full execution payload submitted by the builder, basically. The relay is responsible for selecting the best bid from the builder and carrying out the transaction, basically. So this project was about solving this trust issue, basically, because we are trying to enshrine this. Currently, PBS exists, but outside of the protocol. So it's just basically trying to enshrine it in the protocol, exactly. So, it helps to grant it two major things, right? A proposal payment safety. Proposal payment safety. And a builder payload safety. So, it just goes to say, if an honest builder submits a payload and commits to a particular beacon block, it should always get paid, or he or she should always get paid. And the Builder Payload Safety Dot basically means if it publishes a payload, then that block should become canonical. So, core changes. Basically, our approach was basically just it's a research work that has been in the pipeline for a long while. So, what we did was basically implementing it based on the spec that had already been written. So, the major changes were like, in the execution layer implementing it based on the spec that had already been written, right? So the major changes were like, in the execution layer, there was no changes required. So basically it keeps the execution people happy. Then we just had to make sure almost all the implementation had to be done on the consensus layer, which was like, the two major parts was the beacon chain and the fork choice logic. The fork choice logic is quite complex really, but quite complex because currently that's the point we are at and there's a new design, so that's what we are implementing next with the guy. All right. I'm going to expand on that a bit. So basically, for choice, when we started the project, we had basically two designs. One is like block auction and slot auction but the end of the project whatever like what I was built was basically replaced by a new design thanks to Francesco yeah I'm gonna explain like what what what we did during the cohort and like what what was the design that we are working on. Yeah, so basically this, what EPPS does is separate the consensus and execution validation of the block, which means that right now, the Ethereum block has only like two seconds to do everything, like validate DA or produce the KCG pros. So what this will do is separate the consensus block from the execution block. So for the first three seconds, proposers or validators can validate the consensus block and the execution validation can be deferred to the next three seconds of the next lot of the first three seconds of the next lot. So basically you will get like 12 to 15 seconds to validate DA instead of one or two. And then also there will be like more time to produce KCG proofs. Since like consensus block no longer carries execution, there's also results in faster propagation, like faster network propagation and verification of that. And yeah, this also ensures that CSS liveness no longer depends on the execution results or the finality of the execution block. One last point here is like any builder can set the floor for the auction through P2P market space. This remains unchanged. This is what happens right now, except this is done on an off-protocol relay network. So basically this is what an EPBS slot looks like. So it is divided in basically four intervals. The first three second is when honest validators would gather signed bits or like the signed execution payload header from builders and then submit their consensus block or we call it signed beacon block with these bits. For the second part, it remains unchanged as it is right now. Honest validators will submit their attestations, which is happening right now as well. For the third interval, the aggregators would aggregate these attestations and the builder broadcast either the full payload or a message indicating whether they are withholding the payload or, yeah, I think basically that's it. For the fourth interval, some variators are selected to form a new payload timeliness committee, payload timeliness committee, which kind of attests to the presence and timeliness of the, timeliness of the builder's payload. Okay. Yeah, so this is like what, okay. Yeah, so at any given slot, the blockchains had, can be like a block, can be like a block from a previous slot if the current slot's proposer did not submit a block. So in this case, all the validators would attach to the parent block, and then the slot would go without a block. In the second case, it would be an empty block if proposer does not submit any block in the current slot, but the builder, sorry, if the proposer submits a block in the current slot and the builder did not reveal any payload on time. And in the third case, it would be like a full block when both proposer and builder would reveal the block on time. Yeah, so this was the initial fork choice rule that we are basing our implementation on. This is called block auction design, which contained new payload and withdrawal boost. So basically this is what our mentors tested just two days before the DevCon. I think, yeah, it's on 7th. Yeah. So this assumes that the block here, sorry, yeah, the block propagated here assumes that it is tested on local interop, and meaning that the proposer and builder are the same entities. We haven't tested, I think, on the P2P side of things yet. But yeah, for the future work, implement the new Fortress design. If you have time, I can expand on that a bit more. But yeah, and then hope that more clients join our, more clients join and start the implementation for ePPS. I think Taeku has already started it, and Caleb and I am working on Nimbus, and I think Portus and Terence have been working relentlessly on the present side of things. Yeah, and then update the fork choose consensus spec according to the new design. Do the spec test and at last do the down net testing. I don't know if you have time. Yeah, this is a new, this is what a slot would look like in a new fork choice design. This was proposed by Francesco in the last EPBS breakout room. This basically combines EPBS, Fossil, and DAS into a unified fork choice framework. And it will support all three of this, all in one fork choice, which will work for all of them. So it basically uses availability committee. So the payload timeliness committee is like renamed to the availability committee here. And like now it doesn't only just votes on the timeliness of the blog, but also votes on the payload and the blog availability. Yeah, while also enforcing the inclusion list through deadlines. So if you see i think uh it's at the 10th second uh if uh if so there's like a deadline for freezing freezing of including the ielts uh on uh that's uh that's what basically uh i uh il committee kind of ensures uh not to more more go more on deep on the fossil side of things, but if we include fossil, it also touches the execution side of things. Finally, a special thanks to all the mentors, Porter, Terence, and Tercek, and the excellent EF researchers who came up with the new simple design, Barnaby and Francesco, and Mario and Josh for organizing this EPF. Thank you. Thank you very much guys. Thank you for the kind words. So before we wrap it up, do we have any questions, comments for Caleb and Kira? There is a ton of stuff, a lot of work done on both implementations. I think it's incredible, guys. And if you have any thoughts about it, any comments, any questions, feel free to raise your hand. And yeah, okay. Otherwise, I guess we'll wrap it up here. Yeah. If there is anything, I mean, we will be hanging around. Feel free to reach us out. Thank you so much, guys. And yeah, with this presentation, yeah, let's give it up once again for Kira and Caleb. Thank you so much, guys. Incredible work, and yeah, this right now we are finishing the morning block of",
+ "eventId": "devcon-7",
+ "slot_start": 1731477600000,
+ "slot_end": 1731478500000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1XP6W6A3-lCz0aeamZyGShkdG9rB-Lpip1Ceasz22olM",
+ "resources_slides": null,
+ "speakers": [
+ "kira",
+ "caleb"
+ ]
+ },
+ "vector": [
0,
0,
0,
@@ -257440,6 +257070,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -257527,7 +257158,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -257537,63 +257167,16 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "eip-7702-a-technical-deep-dive",
- "sourceId": "NNNPLC",
- "title": "EIP-7702: a technical deep dive",
- "description": "We'll discuss some of the design goals that lead to EIP-7702, how it works, and what will be possible for users after the Pectra network upgrade.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Expert",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "tags": [
- "Core Protocol",
- "Account Abstraction",
- "eip",
- "Account Abstraction",
- "Core Protocol"
- ],
- "keywords": [
- "EIP"
- ],
- "duration": 1299,
- "language": "en",
- "sources_swarmHash": "d4c1051f49830760c82a47ec5d0413b0d5fef571e4c09d5a7a0c76f69753c619",
- "sources_youtubeId": "_k5fKlKBWV4",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731393000000,
- "slot_end": 1731394800000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/15huammnvrT8ljoiAi9Bnn4jcV_r6L0sm3_gBK-LqQ-4",
- "resources_slides": null,
- "speakers": [
- "lightclient"
- ]
- },
- "vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -257754,6 +257337,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -258225,6 +257809,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -258238,6 +257823,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -258257,6 +257843,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -258360,33 +257947,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -258627,47 +258187,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -258846,9 +258365,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -258861,10 +258382,65 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "eips-simplified-history-and-process-explained",
+ "sourceId": "TBY8MK",
+ "title": "EIPs Simplified: History and Process Explained",
+ "description": "It is planned to be an easy-to-understand session about Ethereum Improvement Proposals (EIPs). We'll explore the interesting history of EIPs and the important moments that have shaped different types and categories of proposals. Learn how EIPs go from an idea to becoming part of the Ethereum network, and see how editors help improve the standardization process. This talk is perfect for anyone who wants to learn about EIPs without getting into technical details.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Community",
+ "featured": true,
+ "doNotRecord": false,
+ "tags": [
+ "Core Protocol",
+ "ACD",
+ "Coordination",
+ "Governance",
+ "improvement",
+ "eip",
+ "processes",
+ "ACD",
+ "Coordination",
+ "Core Protocol",
+ "Governance"
+ ],
+ "keywords": [
+ "EIP",
+ "Process",
+ "Improvement"
+ ],
+ "duration": 125,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732c15e80d989c5b76a202e.vtt",
+ "transcript_text": "สวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนอันนี้ก็จะเป็นสิ่งที่เราจะอยู่ในโชว์ที่นี่ลองที่นี่ค่ะโอบีมีปัญหาหรือครับโอบีมีปัญหาหรือครับป้ายครับผม แล้วพออุณครับโอเค มาแล้วโอ้ยพร้อมพร้อม สตรีม เร็กคอร์ดเรียบร้อย Thank you.",
+ "eventId": "devcon-7",
+ "slot_start": 1731389400000,
+ "slot_end": 1731391200000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1kJKEZ4wRwEX_SUXgxNa4xYGnxsnpoukmIzmPr2XQ64A",
+ "resources_slides": null,
+ "speakers": [
+ "hudson-jameson",
+ "pooja-ranjan"
+ ]
+ },
+ "vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -258905,8 +258481,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -258919,52 +258493,6 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "eip-7732-enshrined-proposer-builder-separation",
- "sourceId": "TKBF9R",
- "title": "[EIP-7732] enshrined Proposer Builder Separation",
- "description": "ePBS implementation in Prysm and Nimbus, fundamentally aimed at solving about solving trust issues. We're gonna discuss the block-auction, slot-auction and the approach proposed by Francesco during the cohort. Some technical challenges and problems that we came across like separating EL and CL block, PTC committee etc.",
- "track": "[CLS] EPF Day",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "tags": [
- "Censorship Resistance",
- "Consensus",
- "Core Protocol",
- "PBS"
- ],
- "keywords": [
- "ePBS",
- "EIP-7732"
- ],
- "duration": 751,
- "language": "en",
- "sources_swarmHash": "e326ff4a5c85f7cfdcbb4ccebbd229632df88de258c3b4daa59aac0bad48ad30",
- "sources_youtubeId": "P2DkizLb79w",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734486c9dbb7a90e1866fa0.vtt",
- "transcript_text": " Hi, good afternoon everyone. So my name is Caleb. I've been working on the PBS implementation in the Nimbus consensus clients. So coming into EPF, the motivation for me initially was choosing a project that touched on almost every major part of the consensus client because I wanted to have a deeper understanding of the protocol in itself. So I decided to choose EIP-7732 and try and propose a builder separation. It was proposed to be implemented in Nimbus. I've been praising it initially, but there was a need for client diversity and to have it implemented in Nimbus, I mean, Prism initially, but there was need for client diversity and to have it implemented in multiple clients. So basically what the AIP does is basically separating the Ethereum block into a consensus and execution, into the consensus and execution parts basically. So it adds a mechanism for the proposer to be able to choose a builder on chain or on protocol, which is currently done off protocol. So it fundamentally changes the way a block is validated by decoupling the execution validation from the consensus validation. So currently, beacon block proposers, they request the hash tree route from a third-party builder via a relay. They submit a signed blinded Beacon Block to that trusted relay. The relay is responsible for replacing that hash tree route with the full execution payload submitted by the builder, basically. The relay is responsible for selecting the best bid from the builder and carrying out the transaction, basically. So this project was about solving this trust issue, basically, because we are trying to enshrine this. Currently, PBS exists, but outside of the protocol. So it's just basically trying to enshrine it in the protocol, exactly. So, it helps to grant it two major things, right? A proposal payment safety. Proposal payment safety. And a builder payload safety. So, it just goes to say, if an honest builder submits a payload and commits to a particular beacon block, it should always get paid, or he or she should always get paid. And the Builder Payload Safety Dot basically means if it publishes a payload, then that block should become canonical. So, core changes. Basically, our approach was basically just it's a research work that has been in the pipeline for a long while. So, what we did was basically implementing it based on the spec that had already been written. So, the major changes were like, in the execution layer implementing it based on the spec that had already been written, right? So the major changes were like, in the execution layer, there was no changes required. So basically it keeps the execution people happy. Then we just had to make sure almost all the implementation had to be done on the consensus layer, which was like, the two major parts was the beacon chain and the fork choice logic. The fork choice logic is quite complex really, but quite complex because currently that's the point we are at and there's a new design, so that's what we are implementing next with the guy. All right. I'm going to expand on that a bit. So basically, for choice, when we started the project, we had basically two designs. One is like block auction and slot auction but the end of the project whatever like what I was built was basically replaced by a new design thanks to Francesco yeah I'm gonna explain like what what what we did during the cohort and like what what was the design that we are working on. Yeah, so basically this, what EPPS does is separate the consensus and execution validation of the block, which means that right now, the Ethereum block has only like two seconds to do everything, like validate DA or produce the KCG pros. So what this will do is separate the consensus block from the execution block. So for the first three seconds, proposers or validators can validate the consensus block and the execution validation can be deferred to the next three seconds of the next lot of the first three seconds of the next lot. So basically you will get like 12 to 15 seconds to validate DA instead of one or two. And then also there will be like more time to produce KCG proofs. Since like consensus block no longer carries execution, there's also results in faster propagation, like faster network propagation and verification of that. And yeah, this also ensures that CSS liveness no longer depends on the execution results or the finality of the execution block. One last point here is like any builder can set the floor for the auction through P2P market space. This remains unchanged. This is what happens right now, except this is done on an off-protocol relay network. So basically this is what an EPBS slot looks like. So it is divided in basically four intervals. The first three second is when honest validators would gather signed bits or like the signed execution payload header from builders and then submit their consensus block or we call it signed beacon block with these bits. For the second part, it remains unchanged as it is right now. Honest validators will submit their attestations, which is happening right now as well. For the third interval, the aggregators would aggregate these attestations and the builder broadcast either the full payload or a message indicating whether they are withholding the payload or, yeah, I think basically that's it. For the fourth interval, some variators are selected to form a new payload timeliness committee, payload timeliness committee, which kind of attests to the presence and timeliness of the, timeliness of the builder's payload. Okay. Yeah, so this is like what, okay. Yeah, so at any given slot, the blockchains had, can be like a block, can be like a block from a previous slot if the current slot's proposer did not submit a block. So in this case, all the validators would attach to the parent block, and then the slot would go without a block. In the second case, it would be an empty block if proposer does not submit any block in the current slot, but the builder, sorry, if the proposer submits a block in the current slot and the builder did not reveal any payload on time. And in the third case, it would be like a full block when both proposer and builder would reveal the block on time. Yeah, so this was the initial fork choice rule that we are basing our implementation on. This is called block auction design, which contained new payload and withdrawal boost. So basically this is what our mentors tested just two days before the DevCon. I think, yeah, it's on 7th. Yeah. So this assumes that the block here, sorry, yeah, the block propagated here assumes that it is tested on local interop, and meaning that the proposer and builder are the same entities. We haven't tested, I think, on the P2P side of things yet. But yeah, for the future work, implement the new Fortress design. If you have time, I can expand on that a bit more. But yeah, and then hope that more clients join our, more clients join and start the implementation for ePPS. I think Taeku has already started it, and Caleb and I am working on Nimbus, and I think Portus and Terence have been working relentlessly on the present side of things. Yeah, and then update the fork choose consensus spec according to the new design. Do the spec test and at last do the down net testing. I don't know if you have time. Yeah, this is a new, this is what a slot would look like in a new fork choice design. This was proposed by Francesco in the last EPBS breakout room. This basically combines EPBS, Fossil, and DAS into a unified fork choice framework. And it will support all three of this, all in one fork choice, which will work for all of them. So it basically uses availability committee. So the payload timeliness committee is like renamed to the availability committee here. And like now it doesn't only just votes on the timeliness of the blog, but also votes on the payload and the blog availability. Yeah, while also enforcing the inclusion list through deadlines. So if you see i think uh it's at the 10th second uh if uh if so there's like a deadline for freezing freezing of including the ielts uh on uh that's uh that's what basically uh i uh il committee kind of ensures uh not to more more go more on deep on the fossil side of things, but if we include fossil, it also touches the execution side of things. Finally, a special thanks to all the mentors, Porter, Terence, and Tercek, and the excellent EF researchers who came up with the new simple design, Barnaby and Francesco, and Mario and Josh for organizing this EPF. Thank you. Thank you very much guys. Thank you for the kind words. So before we wrap it up, do we have any questions, comments for Caleb and Kira? There is a ton of stuff, a lot of work done on both implementations. I think it's incredible, guys. And if you have any thoughts about it, any comments, any questions, feel free to raise your hand. And yeah, okay. Otherwise, I guess we'll wrap it up here. Yeah. If there is anything, I mean, we will be hanging around. Feel free to reach us out. Thank you so much, guys. And yeah, with this presentation, yeah, let's give it up once again for Kira and Caleb. Thank you so much, guys. Incredible work, and yeah, this right now we are finishing the morning block of",
- "eventId": "devcon-7",
- "slot_start": 1731477600000,
- "slot_end": 1731478500000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1XP6W6A3-lCz0aeamZyGShkdG9rB-Lpip1Ceasz22olM",
- "resources_slides": null,
- "speakers": [
- "kira",
- "caleb"
- ]
- },
- "vector": [
0,
0,
0,
@@ -258980,8 +258508,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -259193,6 +258719,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -259247,8 +258775,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -259678,6 +259204,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -259722,7 +259249,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -259736,7 +259262,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -259815,6 +259340,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -259865,14 +259391,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -259952,6 +259470,10 @@
0,
0,
0,
+ 2,
+ 2,
+ 2,
+ 2,
0,
0,
0,
@@ -260224,6 +259746,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -260232,6 +259755,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -260239,6 +259763,41 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "elevate-your-vibration-reggae-sesh-w-rafamilkz-and-friends",
+ "sourceId": "NNFDDB",
+ "title": "Elevate your vibration! (reggae-sesh w/ rafamilkz & friends)",
+ "description": "A reggae jam music sesh performed with soul and heart by web 3 builders & musicians, with the goal of elevating the vibration of Devcon, fostering an environment of peace, love and community! \r\nI have a list of songs to play (guitar and voice), and will have other musicians (cheers to Shaka!) to perform with me and increase the vibrations!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "Beginner",
+ "audience": "Community",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "music",
+ "relaxation",
+ "fun"
+ ],
+ "tags": [
+ "Art",
+ "Marketing"
+ ],
+ "language": "en",
+ "speakers": [
+ "rafamilkz"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731574800000,
+ "slot_end": 1731577500000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/14nyL7Ln8KMC-c1thokTKnggtUR8lxRb5WI3bRH2a-uQ"
+ },
+ "vector": [
0,
0,
0,
@@ -260248,6 +259807,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -260278,11 +259838,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -260295,65 +259853,10 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "eips-simplified-history-and-process-explained",
- "sourceId": "TBY8MK",
- "title": "EIPs Simplified: History and Process Explained",
- "description": "It is planned to be an easy-to-understand session about Ethereum Improvement Proposals (EIPs). We'll explore the interesting history of EIPs and the important moments that have shaped different types and categories of proposals. Learn how EIPs go from an idea to becoming part of the Ethereum network, and see how editors help improve the standardization process. This talk is perfect for anyone who wants to learn about EIPs without getting into technical details.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Community",
- "featured": true,
- "doNotRecord": false,
- "tags": [
- "Core Protocol",
- "ACD",
- "Coordination",
- "Governance",
- "improvement",
- "eip",
- "processes",
- "ACD",
- "Coordination",
- "Core Protocol",
- "Governance"
- ],
- "keywords": [
- "EIP",
- "Process",
- "Improvement"
- ],
- "duration": 125,
- "language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732c15e80d989c5b76a202e.vtt",
- "transcript_text": "สวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนสวัสดีครับ ทุกคนอันนี้ก็จะเป็นสิ่งที่เราจะอยู่ในโชว์ที่นี่ลองที่นี่ค่ะโอบีมีปัญหาหรือครับโอบีมีปัญหาหรือครับป้ายครับผม แล้วพออุณครับโอเค มาแล้วโอ้ยพร้อมพร้อม สตรีม เร็กคอร์ดเรียบร้อย Thank you.",
- "eventId": "devcon-7",
- "slot_start": 1731389400000,
- "slot_end": 1731391200000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1kJKEZ4wRwEX_SUXgxNa4xYGnxsnpoukmIzmPr2XQ64A",
- "resources_slides": null,
- "speakers": [
- "hudson-jameson",
- "pooja-ranjan"
- ]
- },
- "vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -260580,6 +260083,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -260633,8 +260137,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -261120,7 +260622,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -261154,6 +260655,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -261197,7 +260699,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -261256,7 +260757,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -261336,6 +260836,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -261387,59 +260888,6 @@
0,
0,
0,
- 2,
- 2,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -261669,8 +261117,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -261684,34 +261130,48 @@
},
{
"session": {
- "id": "elevate-your-vibration-reggae-sesh-w-rafamilkz-and-friends",
- "sourceId": "NNFDDB",
- "title": "Elevate your vibration! (reggae-sesh w/ rafamilkz & friends)",
- "description": "A reggae jam music sesh performed with soul and heart by web 3 builders & musicians, with the goal of elevating the vibration of Devcon, fostering an environment of peace, love and community! \r\nI have a list of songs to play (guitar and voice), and will have other musicians (cheers to Shaka!) to perform with me and increase the vibrations!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "elliptic-curves-and-snarks-past-present-and-future",
+ "sourceId": "Y3PMMA",
+ "title": "Elliptic curves and SNARKs: past, present and future.",
+ "description": "Elliptic curves are used in many proof systems. Some systems (e.g. Bulletproofs) use plain curves (e.g. ed25519). Some (e.g. Groth16, KZG-PLONK) use pairing-friendly curves (e.g. BLS12-381). Some recursive systems require pairing-friendly 2-cycle (e.g. MNT4/6) or 2-chains (e.g. BLS12-377/BW6-761). Some other recursive/folding systems require plain 2-cycle (e.g. Pasta). In this talk we will go through the difference between these curves and why there isn't a silver bullet curve for all scenarios.",
+ "track": "Applied Cryptography",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "music",
- "relaxation",
- "fun"
- ],
"tags": [
- "Art",
- "Marketing"
+ "ZKP",
+ "Cryptography",
+ "SNARK",
+ "elliptic",
+ "curves",
+ "Cryptography",
+ "SNARK",
+ "ZKP"
],
- "language": "en",
- "speakers": [
- "rafamilkz"
+ "keywords": [
+ "elliptic",
+ "curves"
],
+ "duration": 1518,
+ "language": "en",
+ "sources_swarmHash": "d418d4f93106c8a1c844d7ddadd6ef00204c7d15d551d1e3a9732f82c007bf46",
+ "sources_youtubeId": "Bey043R_52k",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67335bf23a168eb535971501.vtt",
+ "transcript_text": " Hi everyone, my name is Yousef. Yeah, so I'm a cryptographer at ConsenSys working on Gnark, the zk-snark library, and Linear, the zk-evm. And today I'm going gonna talk about elliptic curves on snarks. So I have two problems in my life. One, getting my wife to choose a restaurant, difficult one. And two, Ethereum supports only BN254 precompiles. So today I'm gonna talk about the second problem because first one we need more time, right? So what are these BN254 precompiles so BN254 is a elliptic curve so it is this mathematical objects on which we can do some sort of cryptography and mainly these three operations that we call precompile so they are like native smart contracting ethereum so you can do addition like take two points and add them, have a third point. And you can do scalar multiplication, which is if you multiply a scalar by a point. So you get another point, which is like adding the points and times to itself, and the scalar. And pairing product check, where you have some billionaire map that takes points on elliptic curves, output them on some line, some extension field, and multiplies these and check if it is one. So I'm not going to talk in detail about these operations, but you can look at the illustrations and pretend you got it. So what is most important is what is is useful for doing snag verification on Ethereum, doing BLS signature verification on Ethereum, like doing some polynomial commitment like KZG verification on Ethereum, and some vehicle trees, at least with what we have for now. And so we've talked about BN254 as an elliptic curve, but there are so many elliptic curves in the wild, and what I'm trying to explain today is why there isn't like a single silver bullet curve to rule them all. So you might have heard of BLS-2381, SECP-256, so used for ECDSA signature or Ethereum. If you change a letter, you have another curve you might have heard of ED 25519 some two chains some cycles like pasta twiddle some fancier names like job job bender snatch gramke and some new names like lollipops yeah so many names so what i want to start with is some definitions of what is past, present, and future, right? So past are curves that have been used in SNARKs, but not anymore. Present, curves that are still being used in SNARKs today. And future is curves that already exist in the wild, but not used in SNARKs just yet. So if we follow this color scheme, then yeah. So we have some green ones in the past, like MNTs or Twitter Cycles, some blue, like BLS or 2Chains, and some future purple, like Lollipops. And yeah, we see that BN is half blue, half green. That is because it is still used in Ethereum, but it's not secure anymore, or at least it doesn't have the targeted security. So to organize this mess, I propose to categorize it into three columns. So I'm calling non-pairing-friendly curves, pairing-friendly curves, and in-circuit curves. So again, this pre-compiles. I talked about pairings, but not all the elliptic curves are equipped with pairings, or at least not efficiently. And if your SNARK doesn't need pairings, so you can use the curves in the first column. If your SNARK needs pairings, then you need curves on the second column. And in-circuit curves are this kind of curves that were built in purpose to do some computations over the SNARK. Not to do the SNARK, but just, I don't know, you want to prove some signature with a SNARK, then maybe building an efficient elliptic curve would help you. So if we take a closer look to the first column, so we have, for example, SNARKs like Bulletproofs or Halo or Nova, they can use the curves from the first column. But then the question is, why there isn't a single curve? Well, it depends on what you want. If you want performance, then maybe ED25519 is the best curve. If you want standard, maybe the next curve. If you're scared of NIST, maybe you choose another standard like Bitcoin or Ethereum curve, like SICP. If you want a recursion, that is, you want to do a proof of a proof, then maybe you can use SICU if you want compatibility with SICP. If you do not care about compatibility, you just want performance, then Twitter. If you want more performance, then PASTA. If you want hybrid recursion, that is a SNARK from the first column and a SNARK in the second column, then maybe Pluto-Aries or Gramkin, BN if you want compatibility with Ethereum. What about the second column? So the second column is for SNARKs that are pairing-based. Those are like GOT16 or anything that is based on KZG, like Planck, for instance. So you can use any curve in the second column. And then, again, why there isn't a single curve if you want Ethereum compatibility then BN if you want performance BLS12 if you want one recursion that is a proof of a proof maybe you want to use two chains if you want infinite recursion with pairing base so you have stuck with MNTs but these are slow either slow or secure if you had some hybrid recursion then you can also have other propositions here. So the last column is so for example if you want to prove some signatures like EDDSA or ECDSA or some specific hashes on elliptic curves or some vertical trees then you can choose from this third column but then again if you want just elliptic curve cryptography you might want to use job, if you want just elliptic curve cryptography, you might want to use job-job. If you want faster elliptic curve cryptography, maybe bandersnatch. If you want pairing-based cryptography, then you need, for example, two chains or cycles, then BW6 or MNT. Either you want one recursion or infinite recursion. If you want to mix things and make them succinctness, maybe the lollipops if you want to make them compatible with bn then maybe gramcane so this is why we do not have like a single elliptic curve but on ethereum we have a single elliptic curve so what i want to talk about next is the story so far so goldwasser micali and wacko they invented zero knowledge rules and there have been a lot of papers, both on the practical side and the theoretical side since. Yeah, a lot. But what I want to focus on is pairing-based SNARKs, because those constructions, they were based on different assumptions, and even those that were based on elliptic curves, we didn't care about which elliptic curves, because we can take any one. But starting with pairing-based, we started constructing elliptic curves in purpose for SNARCs. And for me, the turning point was this paper by Bonego and Nissim. It has nothing to do with SNARCs. It is a doubly homomorphic encryption scheme. That is, you can do any additions you want on the ciphertext and a single multiplication on the ciphertext. But it wasn't practical, and this is because for the decryption we needed to solve a discrete logarithm problem. So not practical. But fortunately, so researchers like Grossig, Gortz, Ostrovsky, and Sahai, between 2006 until 2010, they built on top of this idea of W homomorphic encryption because they said, well, it's not practical, but maybe in ZKPs we do not need to do decryption. We just need some sort of a commitment. Then maybe we can ditch decryption and we can have zero-knowledge truth. And they did this. But we didn't have implementation at that point. And the turning point implementation-wise was this paper by Gennaro et al. They propose insightful constructions for polynomial commitments. And mixing this with the pairing-based papers, pairing-based SNARK papers, well, we started having implementation. And the first implementation I'm aware of is this paper called Pinocchio. and when I looked at the code it was proprietary still now but they used our BN256 curve from another paper in 2010 by Nariga Hall and it was it had the 128 bit security at that time and two ADCT 5 so the term was not coined to ADCT at that time but it just means for now like let's say, a performance metric. A few months later, there was this paper, Parni, where they implemented BST side license Pinocchio with another elliptic curve, BN254, from another paper in 2010. And it has a 2-addicity 45 at that time, even if we didn't know about what is 2-ADCT is for. So same year, so Ben Sasson, Chiesa, and others, they implemented Pinocchio, a variant, and they used a very specific elliptic code that I'm calling GMV6183. It is due to a paper to Galbraith, McKee, and Valensan. The implementation is still there today in LibFF. It has a 2-ADCT 31. The 2-ADCT notion was introduced in this paper, but it had a security 80-bit. So it is like, for those who know, it's just like an MNT curve, but with a cofactor equal to 4, so that they have like a twisted Edward form. So next year, pretty much the same authors, they proposed the BN, the famous BN254 curve, the curve that we are using today in Ethereum. And what they wanted is a two-addicity term. I mean, BN curves were used in pairing-based cryptography, but in Snarks, they wanted a two-addicity. So they constructed this curve with two-addicityicity-28, but my question is why didn't use the curve from pantry which has already a 45-2-oddicity and both on the prime field, the base field and the scalar field. And yeah, I mean implementation wise the one that we have today in Ethereum is ugly especially when you construct the tower and this one was pretty much simple. But yeah, pairings were used in cryptography and so the researchers have been working on the cryptanalysis of pairing but the turning point cryptanalysis wise was this paper by Kim and Barbulescu. So they found a new complexity for solving this crypt logarithm problem over extension field. But to give proper credit, it was this paper in 2016, same year, by Meneses, Sarkar, and Singh, where they analyzed the conclusion, I mean, the impact of this Kim and Barberley School paper on the choice of elliptic curves. And in their conclusion, they proposed using BLS-12 curve. And for the record, BLS-12, there were curves from 2001 and BN from 2005. And few people cared about BLS12 because of BN. But because of this paper, we came back to BLS12. And I believe based on that, Fox, Zika, especially, they proposed the famous BLS12381 that we're going to have now in Pektra, upgrading Ethereum. Now, if you want like recursion you need two curves this is what we call two cycle so you need two curves because to to express things efficiently in recursion you need the curves to share some parameters and it was this famous paper scalable zero knowledge via cycles of elliptic curvesves, by Ben Sasson et al., that proposed the first practical setting for recursion, and they devised the MNT4289 and 298 and MNT6298. It has low security, big adhicity, and they also found another cycle, but they updated the paper only in 2020 on Eprint, six years later, I'm sorry, but they shared the parameters with Coda folks, now Mina, and Mina used this at some point. So it is a paper from 2001, the construction of the elliptic curve, due to Miyajima, Kawayashi, and Takano, but just to give proper credit again again so it was a paper of 2008 by Karabina and Teske who established for the first time that MNT4 and MNT6 form a two cycle and yeah so because of security we need big parameters and it was Oror Gievic who gave I think the biggest one so far of size 992 so it is not practical I mean it's it's slow but yeah for research it's there but the to addicity is small and it's very difficult to find a higher security with higher at the city M&T cycles but I think two weeks ago Costello and Korpahl they proposed this paper lollipops of pair infinitely elliptic curves and they solved the problem of higher to addicity for MNT cycles and the idea was pretty much clever they took the MNT cycles I mean the problem with MNT cycles is like you need to solve this pair generalized spell equation and to increase your search space you need to increase the discrete some discrimin you need to increase some discriminants. And the bigger the discriminants, the harder it is to find the curves. Let's put it like this. And what they did is like they took MNTs and they used some super singular elliptic curves with some other algorithm called Borica. And it works, but it is still slow, so it's not practical. And also Santos, Costello, and Naik, they looked at cycles of peri-infant not elliptic curves, but curves in general, and they proposed some mix of elliptic curves, ordinary, super singular, and also some hyper-elliptic curves. So it is as slow as MNT, as far as I can tell, and also it is still early research. So implementation-wise, it's going to be difficult to do like this a billion varieties implementations efficiently now if you want just recursion but not infinite recursion you just need to do a proof of a proof maybe just for aggregation you need two chains so there is this famous paper called Xexi they introduced this curve called BLS2F377 which is used I think in Alio and in Celo and others blockchains and some Cox-Pinch 6 curve in I think 2020 on Eprint at least and same year we proposed another so with another BW6 curve that was more efficient and we generalize this to some other to any elliptical and families but it was just research implementation wise these two curves are like BLS2F and BW6 are the most efficient nowadays for two chains but it wasn't Zexi that introduced the notion of two chains it was five years ago but hidden in some appendix of the paper, Geppetto. So they used the same BN254 curve from Pinocchio, and they built on top of it a BW6 curve, giving the raise to the first implementation of two chain. Yeah, but it was hidden in some appendix. Now, if you want to do a recursion without pairing-friendly snarks, to do a recursion without pairing pairing friendly snacks you just need recursion of some other snacks that do not need bearings then you can use the plane cycles so in the halo paper they introduced the twiddledy to the bone to the d2 cycle and they then they are placed it with pasta which is more efficient And it is used now in Halo 2 implementation. It is used in folding schemes like in the Sonobi implementation. But it was a year before that at least I've seen a two-cycle in the zero-knowledge setting. It was proposed in this website by Andrew Prostra, and it is the SecP-SecU curve, and in his mail he gave the parameters. So for me it was the first one in the zero-knowledge setting. But research-wise, it was in 2011, it was called amicable pairs under adequate cycles, and the Halo paper cites this one actually but actually I was able to find an implementation of plane 2 cycles back to 2007 in a different context for primality testing like when you test primes you can test them with elliptic curves and it was François Morin, his implementation here where he was discarding these plane cycles because they were bad for primality testing and the same year the definition was formalized in this paper by B. Mihailovsky it's called dual elliptic primes so dual elliptic primes amicable pairs aliquot cycles and plane cycles they are all the same thing and I think two weeks two months ago no this this summer I mean this year so Antoine Jou and others they looked at elliptic curves that form cycle from a mathematical point of view and they're calling it elliptic curves over Haas pairs so all of these the same thing and if you want to mix then snark-based, pairing-based snarks and non-pairing-based snarks, you can use hybrid two cycles. So one of them is proposed by Daira Hopu from Zcash. So this is the one. And actually, I was able to find another implementation with BN381 in MINA protocol by Zach Meckler, but I don't think it was used anywhere. It was just experimental. And then if you want compatibility with Ethereum, so Aztec proposed the Gramkin curve that is compatible with BN254 from Ethereum. But actually, I mean, you can take any prime order pairing friendly ellipticals and by definition you can construct a hybrid cycle. And if you want to merge all of these like you want to do a cycle on the two chain so we call it lollipops like you can have a cycle and then a stick it can be pairing friendly it can be non pairing friendly it depends on your use. But together with Antonio Sanso from EF, we proposed a way to build families of, like, when you have a pairing-friendly elliptic curve and on top of it you can have a plane cycle. And then, I think, a couple of days after our paper, Generalized our idea with some other families of curves like KSS. And then, I think, one week ago, on ePrint at least, Aurore and Simon Masson, they proposed an even more general way to construct those lollipops with fixing the curve. Before we couldn't fix the curve, we had to construct all the curves together, but they were able to construct it on, for example, BLS381, for instance. And yeah, then lollipops, they found another way to do the lollipops with all the curves being pairing friendly. It wasn't possible at this point, but they did it with super singular elliptic curves, which are defined over extensions, so make things a bit more slow. Yeah, that's it for me. So many information, but yeah. Thank you. Thank you very much. Very nice, good overview, covered a lot of stuff. There's a few questions, I think two. One that kind of leads into the other, so maybe I can read out to you. So, yeah, I think one that was asked even before the talk started, so I think you have a fan who's wondering, what is the future of curve-based snarks compared to hash-based snarks? I was expecting this question, by the way. I mean, yeah, hash-based snarks, they are fast because you can construct them over smaller fields, so you can speed up things. But I still believe that curve-based snarks, they come with succinctness, so there is like a place for both. And today we see that, for example, for ZKVMs or ZKEVMs, they do a lot of stark proving, so hash-based SNARKs. But then at the end of the day, they compose it or they wrap it with a curve-based SNARK so that they can get Ethereum compatibility one and they can get success, which is like proofs are small. So I think, I believe both are to stay. Good. Then, so do you think recursive SNARK into STARK might present an interest to be post-quantum? Here, SNARK cannot be simulated by post-quantum computer. How SNARK and STARK benches, benchmarks? Okay, so let me try to understand the question. You can pose, yeah. So I think, yes, SNARKs, if we're saying that SNARKs are based on curves, which is not really the case, but I understand it like this. Well, if it is based on curves, it's not post-quantum. STARKs, well, if they are based on hashes, they are plausibly post-quantum. Composing both means that the protocol is not post-quantum. But yeah, if you want post-quantum resistance, then definitely anything that is hash-based. I mean, yeah, you can also talk about isogenies, because these are like curves-based. These are post-quantum, but I'm not aware of any isogeny-based snarks yet. And so I think then the last part of the question, how do they sort of benchmark against each other in terms of efficiency? Yeah, so it depends really on what baseline we're benchmarking against. So it really depends, but for example, if we are taking any... So SNARKs, they work over big fields defined by the elliptic curve. So if we define the statements over this field natively, then it's competitive. But in STOCKs, you can define them over any field. And for example, if you define them over binary field, like Binus, then you can do things like K-Chalk faster. So it really depends on the baseline. Nice. Okay. Good. Some more questions came in in the meantime. We have two minutes left, so we can go into it. Sure. How important is high two-addicity? Can we get away without it? Okay, yeah. So the 2-addicity is... So in ellipticals, we're working over this subgroup of prime order, and the 2-addicity means just this order minus 1 has to be divisible by a high power of 2, and it just means FFT-friendliness, because the best way to implement FFT is like radix to FFT. And for big circuits, then you definitely need this two-adicity. For small circuits, maybe you can get away with smoothness, like just some smooth integers dividing like p minus one. But yeah, for big circuit, like for example, I work on the linear ZKVM. We work on big circuits. So yeah, it's definitely a requirement for us. And why do you want to get away without it? I'm sorry, why? I'm just asking my follow-on, like from my own understanding, why do you want to get away without it? Like what problems does it introduce? Yeah, so it introduces the fact From my own understanding, why do you want to get away without it? What problems does it introduce? Yes, so it introduces the fact that you need a specific elliptic curve. For example, if I'm talking about Ethereum, so Ethereum curve, so the R-1 is divisible by high power of 2, but the P-1 is not. So if you want to do, for example, a recursion of Ethereum, it wouldn't work on the second layer. Yes, yes, Yes, of course. Good. Then last question while we have 30 seconds left. Why is it crucial for recursion to have two curves where one is prime and the other, one prime is the order of the other? Yes. So we express the statement of whatever we want to prove on the subgroup of the elliptic curve. And if we want to do a proof of a proof, we need to do the verification as a statement. But the verification uses these pairings, and pairings are defined over a different field. So if you want to do pairings in the subgroup, you need the field of the pairing to match the field of your subgroup so that computations are native. Otherwise you need to emulate non-native field arithmetic which is quite costly. I mean we do this but it's quite costly. But if you have native then the number of constraints or your proof generation will be way, way faster. Good. I see there are more questions, but we're actually out of time. Maybe you can catch him offline. But yeah, thank you very much. I'm thrilled with the amount of questions. Great. Thank you very much. Thank you.",
"eventId": "devcon-7",
- "slot_start": 1731574800000,
- "slot_end": 1731577500000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/14nyL7Ln8KMC-c1thokTKnggtUR8lxRb5WI3bRH2a-uQ"
+ "slot_start": 1731405600000,
+ "slot_end": 1731407400000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/15MaGmHzAvHj765BvqDHs0ZxiiGevi3H9hscAvkCAGTc",
+ "resources_slides": null,
+ "speakers": [
+ "youssef-el-housni"
+ ]
},
"vector": [
0,
@@ -261723,8 +261183,8 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -262476,6 +261936,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -262537,6 +261998,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -262574,12 +262036,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -262748,6 +262204,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -262757,6 +262214,7 @@
0,
0,
2,
+ 2,
0,
0,
0,
@@ -263026,6 +262484,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -263036,8 +262495,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -263049,48 +262506,25 @@
},
{
"session": {
- "id": "elliptic-curves-and-snarks-past-present-and-future",
- "sourceId": "Y3PMMA",
- "title": "Elliptic curves and SNARKs: past, present and future.",
- "description": "Elliptic curves are used in many proof systems. Some systems (e.g. Bulletproofs) use plain curves (e.g. ed25519). Some (e.g. Groth16, KZG-PLONK) use pairing-friendly curves (e.g. BLS12-381). Some recursive systems require pairing-friendly 2-cycle (e.g. MNT4/6) or 2-chains (e.g. BLS12-377/BW6-761). Some other recursive/folding systems require plain 2-cycle (e.g. Pasta). In this talk we will go through the difference between these curves and why there isn't a silver bullet curve for all scenarios.",
- "track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "embodiment-practice",
+ "sourceId": "LNF8NE",
+ "title": "Embodiment Practice",
+ "description": "By master Zoe\r\n- Gentle guided stretches to connect with the body and open different energy channels\r\n- A blend of embodiment, asana, meditation, breathwork, tapping, and somatics to weave together mind, body, and soul\r\n\r\nNov 13 10:30 - 11:15",
+ "track": "Entertainment",
+ "type": "Mixed Formats",
+ "expertise": "Beginner",
+ "audience": "Hobby",
"featured": false,
"doNotRecord": false,
- "tags": [
- "ZKP",
- "Cryptography",
- "SNARK",
- "elliptic",
- "curves",
- "Cryptography",
- "SNARK",
- "ZKP"
- ],
- "keywords": [
- "elliptic",
- "curves"
- ],
- "duration": 1518,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "d418d4f93106c8a1c844d7ddadd6ef00204c7d15d551d1e3a9732f82c007bf46",
- "sources_youtubeId": "Bey043R_52k",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67335bf23a168eb535971501.vtt",
- "transcript_text": " Hi everyone, my name is Yousef. Yeah, so I'm a cryptographer at ConsenSys working on Gnark, the zk-snark library, and Linear, the zk-evm. And today I'm going gonna talk about elliptic curves on snarks. So I have two problems in my life. One, getting my wife to choose a restaurant, difficult one. And two, Ethereum supports only BN254 precompiles. So today I'm gonna talk about the second problem because first one we need more time, right? So what are these BN254 precompiles so BN254 is a elliptic curve so it is this mathematical objects on which we can do some sort of cryptography and mainly these three operations that we call precompile so they are like native smart contracting ethereum so you can do addition like take two points and add them, have a third point. And you can do scalar multiplication, which is if you multiply a scalar by a point. So you get another point, which is like adding the points and times to itself, and the scalar. And pairing product check, where you have some billionaire map that takes points on elliptic curves, output them on some line, some extension field, and multiplies these and check if it is one. So I'm not going to talk in detail about these operations, but you can look at the illustrations and pretend you got it. So what is most important is what is is useful for doing snag verification on Ethereum, doing BLS signature verification on Ethereum, like doing some polynomial commitment like KZG verification on Ethereum, and some vehicle trees, at least with what we have for now. And so we've talked about BN254 as an elliptic curve, but there are so many elliptic curves in the wild, and what I'm trying to explain today is why there isn't like a single silver bullet curve to rule them all. So you might have heard of BLS-2381, SECP-256, so used for ECDSA signature or Ethereum. If you change a letter, you have another curve you might have heard of ED 25519 some two chains some cycles like pasta twiddle some fancier names like job job bender snatch gramke and some new names like lollipops yeah so many names so what i want to start with is some definitions of what is past, present, and future, right? So past are curves that have been used in SNARKs, but not anymore. Present, curves that are still being used in SNARKs today. And future is curves that already exist in the wild, but not used in SNARKs just yet. So if we follow this color scheme, then yeah. So we have some green ones in the past, like MNTs or Twitter Cycles, some blue, like BLS or 2Chains, and some future purple, like Lollipops. And yeah, we see that BN is half blue, half green. That is because it is still used in Ethereum, but it's not secure anymore, or at least it doesn't have the targeted security. So to organize this mess, I propose to categorize it into three columns. So I'm calling non-pairing-friendly curves, pairing-friendly curves, and in-circuit curves. So again, this pre-compiles. I talked about pairings, but not all the elliptic curves are equipped with pairings, or at least not efficiently. And if your SNARK doesn't need pairings, so you can use the curves in the first column. If your SNARK needs pairings, then you need curves on the second column. And in-circuit curves are this kind of curves that were built in purpose to do some computations over the SNARK. Not to do the SNARK, but just, I don't know, you want to prove some signature with a SNARK, then maybe building an efficient elliptic curve would help you. So if we take a closer look to the first column, so we have, for example, SNARKs like Bulletproofs or Halo or Nova, they can use the curves from the first column. But then the question is, why there isn't a single curve? Well, it depends on what you want. If you want performance, then maybe ED25519 is the best curve. If you want standard, maybe the next curve. If you're scared of NIST, maybe you choose another standard like Bitcoin or Ethereum curve, like SICP. If you want a recursion, that is, you want to do a proof of a proof, then maybe you can use SICU if you want compatibility with SICP. If you do not care about compatibility, you just want performance, then Twitter. If you want more performance, then PASTA. If you want hybrid recursion, that is a SNARK from the first column and a SNARK in the second column, then maybe Pluto-Aries or Gramkin, BN if you want compatibility with Ethereum. What about the second column? So the second column is for SNARKs that are pairing-based. Those are like GOT16 or anything that is based on KZG, like Planck, for instance. So you can use any curve in the second column. And then, again, why there isn't a single curve if you want Ethereum compatibility then BN if you want performance BLS12 if you want one recursion that is a proof of a proof maybe you want to use two chains if you want infinite recursion with pairing base so you have stuck with MNTs but these are slow either slow or secure if you had some hybrid recursion then you can also have other propositions here. So the last column is so for example if you want to prove some signatures like EDDSA or ECDSA or some specific hashes on elliptic curves or some vertical trees then you can choose from this third column but then again if you want just elliptic curve cryptography you might want to use job, if you want just elliptic curve cryptography, you might want to use job-job. If you want faster elliptic curve cryptography, maybe bandersnatch. If you want pairing-based cryptography, then you need, for example, two chains or cycles, then BW6 or MNT. Either you want one recursion or infinite recursion. If you want to mix things and make them succinctness, maybe the lollipops if you want to make them compatible with bn then maybe gramcane so this is why we do not have like a single elliptic curve but on ethereum we have a single elliptic curve so what i want to talk about next is the story so far so goldwasser micali and wacko they invented zero knowledge rules and there have been a lot of papers, both on the practical side and the theoretical side since. Yeah, a lot. But what I want to focus on is pairing-based SNARKs, because those constructions, they were based on different assumptions, and even those that were based on elliptic curves, we didn't care about which elliptic curves, because we can take any one. But starting with pairing-based, we started constructing elliptic curves in purpose for SNARCs. And for me, the turning point was this paper by Bonego and Nissim. It has nothing to do with SNARCs. It is a doubly homomorphic encryption scheme. That is, you can do any additions you want on the ciphertext and a single multiplication on the ciphertext. But it wasn't practical, and this is because for the decryption we needed to solve a discrete logarithm problem. So not practical. But fortunately, so researchers like Grossig, Gortz, Ostrovsky, and Sahai, between 2006 until 2010, they built on top of this idea of W homomorphic encryption because they said, well, it's not practical, but maybe in ZKPs we do not need to do decryption. We just need some sort of a commitment. Then maybe we can ditch decryption and we can have zero-knowledge truth. And they did this. But we didn't have implementation at that point. And the turning point implementation-wise was this paper by Gennaro et al. They propose insightful constructions for polynomial commitments. And mixing this with the pairing-based papers, pairing-based SNARK papers, well, we started having implementation. And the first implementation I'm aware of is this paper called Pinocchio. and when I looked at the code it was proprietary still now but they used our BN256 curve from another paper in 2010 by Nariga Hall and it was it had the 128 bit security at that time and two ADCT 5 so the term was not coined to ADCT at that time but it just means for now like let's say, a performance metric. A few months later, there was this paper, Parni, where they implemented BST side license Pinocchio with another elliptic curve, BN254, from another paper in 2010. And it has a 2-addicity 45 at that time, even if we didn't know about what is 2-ADCT is for. So same year, so Ben Sasson, Chiesa, and others, they implemented Pinocchio, a variant, and they used a very specific elliptic code that I'm calling GMV6183. It is due to a paper to Galbraith, McKee, and Valensan. The implementation is still there today in LibFF. It has a 2-ADCT 31. The 2-ADCT notion was introduced in this paper, but it had a security 80-bit. So it is like, for those who know, it's just like an MNT curve, but with a cofactor equal to 4, so that they have like a twisted Edward form. So next year, pretty much the same authors, they proposed the BN, the famous BN254 curve, the curve that we are using today in Ethereum. And what they wanted is a two-addicity term. I mean, BN curves were used in pairing-based cryptography, but in Snarks, they wanted a two-addicity. So they constructed this curve with two-addicityicity-28, but my question is why didn't use the curve from pantry which has already a 45-2-oddicity and both on the prime field, the base field and the scalar field. And yeah, I mean implementation wise the one that we have today in Ethereum is ugly especially when you construct the tower and this one was pretty much simple. But yeah, pairings were used in cryptography and so the researchers have been working on the cryptanalysis of pairing but the turning point cryptanalysis wise was this paper by Kim and Barbulescu. So they found a new complexity for solving this crypt logarithm problem over extension field. But to give proper credit, it was this paper in 2016, same year, by Meneses, Sarkar, and Singh, where they analyzed the conclusion, I mean, the impact of this Kim and Barberley School paper on the choice of elliptic curves. And in their conclusion, they proposed using BLS-12 curve. And for the record, BLS-12, there were curves from 2001 and BN from 2005. And few people cared about BLS12 because of BN. But because of this paper, we came back to BLS12. And I believe based on that, Fox, Zika, especially, they proposed the famous BLS12381 that we're going to have now in Pektra, upgrading Ethereum. Now, if you want like recursion you need two curves this is what we call two cycle so you need two curves because to to express things efficiently in recursion you need the curves to share some parameters and it was this famous paper scalable zero knowledge via cycles of elliptic curvesves, by Ben Sasson et al., that proposed the first practical setting for recursion, and they devised the MNT4289 and 298 and MNT6298. It has low security, big adhicity, and they also found another cycle, but they updated the paper only in 2020 on Eprint, six years later, I'm sorry, but they shared the parameters with Coda folks, now Mina, and Mina used this at some point. So it is a paper from 2001, the construction of the elliptic curve, due to Miyajima, Kawayashi, and Takano, but just to give proper credit again again so it was a paper of 2008 by Karabina and Teske who established for the first time that MNT4 and MNT6 form a two cycle and yeah so because of security we need big parameters and it was Oror Gievic who gave I think the biggest one so far of size 992 so it is not practical I mean it's it's slow but yeah for research it's there but the to addicity is small and it's very difficult to find a higher security with higher at the city M&T cycles but I think two weeks ago Costello and Korpahl they proposed this paper lollipops of pair infinitely elliptic curves and they solved the problem of higher to addicity for MNT cycles and the idea was pretty much clever they took the MNT cycles I mean the problem with MNT cycles is like you need to solve this pair generalized spell equation and to increase your search space you need to increase the discrete some discrimin you need to increase some discriminants. And the bigger the discriminants, the harder it is to find the curves. Let's put it like this. And what they did is like they took MNTs and they used some super singular elliptic curves with some other algorithm called Borica. And it works, but it is still slow, so it's not practical. And also Santos, Costello, and Naik, they looked at cycles of peri-infant not elliptic curves, but curves in general, and they proposed some mix of elliptic curves, ordinary, super singular, and also some hyper-elliptic curves. So it is as slow as MNT, as far as I can tell, and also it is still early research. So implementation-wise, it's going to be difficult to do like this a billion varieties implementations efficiently now if you want just recursion but not infinite recursion you just need to do a proof of a proof maybe just for aggregation you need two chains so there is this famous paper called Xexi they introduced this curve called BLS2F377 which is used I think in Alio and in Celo and others blockchains and some Cox-Pinch 6 curve in I think 2020 on Eprint at least and same year we proposed another so with another BW6 curve that was more efficient and we generalize this to some other to any elliptical and families but it was just research implementation wise these two curves are like BLS2F and BW6 are the most efficient nowadays for two chains but it wasn't Zexi that introduced the notion of two chains it was five years ago but hidden in some appendix of the paper, Geppetto. So they used the same BN254 curve from Pinocchio, and they built on top of it a BW6 curve, giving the raise to the first implementation of two chain. Yeah, but it was hidden in some appendix. Now, if you want to do a recursion without pairing-friendly snarks, to do a recursion without pairing pairing friendly snacks you just need recursion of some other snacks that do not need bearings then you can use the plane cycles so in the halo paper they introduced the twiddledy to the bone to the d2 cycle and they then they are placed it with pasta which is more efficient And it is used now in Halo 2 implementation. It is used in folding schemes like in the Sonobi implementation. But it was a year before that at least I've seen a two-cycle in the zero-knowledge setting. It was proposed in this website by Andrew Prostra, and it is the SecP-SecU curve, and in his mail he gave the parameters. So for me it was the first one in the zero-knowledge setting. But research-wise, it was in 2011, it was called amicable pairs under adequate cycles, and the Halo paper cites this one actually but actually I was able to find an implementation of plane 2 cycles back to 2007 in a different context for primality testing like when you test primes you can test them with elliptic curves and it was François Morin, his implementation here where he was discarding these plane cycles because they were bad for primality testing and the same year the definition was formalized in this paper by B. Mihailovsky it's called dual elliptic primes so dual elliptic primes amicable pairs aliquot cycles and plane cycles they are all the same thing and I think two weeks two months ago no this this summer I mean this year so Antoine Jou and others they looked at elliptic curves that form cycle from a mathematical point of view and they're calling it elliptic curves over Haas pairs so all of these the same thing and if you want to mix then snark-based, pairing-based snarks and non-pairing-based snarks, you can use hybrid two cycles. So one of them is proposed by Daira Hopu from Zcash. So this is the one. And actually, I was able to find another implementation with BN381 in MINA protocol by Zach Meckler, but I don't think it was used anywhere. It was just experimental. And then if you want compatibility with Ethereum, so Aztec proposed the Gramkin curve that is compatible with BN254 from Ethereum. But actually, I mean, you can take any prime order pairing friendly ellipticals and by definition you can construct a hybrid cycle. And if you want to merge all of these like you want to do a cycle on the two chain so we call it lollipops like you can have a cycle and then a stick it can be pairing friendly it can be non pairing friendly it depends on your use. But together with Antonio Sanso from EF, we proposed a way to build families of, like, when you have a pairing-friendly elliptic curve and on top of it you can have a plane cycle. And then, I think, a couple of days after our paper, Generalized our idea with some other families of curves like KSS. And then, I think, one week ago, on ePrint at least, Aurore and Simon Masson, they proposed an even more general way to construct those lollipops with fixing the curve. Before we couldn't fix the curve, we had to construct all the curves together, but they were able to construct it on, for example, BLS381, for instance. And yeah, then lollipops, they found another way to do the lollipops with all the curves being pairing friendly. It wasn't possible at this point, but they did it with super singular elliptic curves, which are defined over extensions, so make things a bit more slow. Yeah, that's it for me. So many information, but yeah. Thank you. Thank you very much. Very nice, good overview, covered a lot of stuff. There's a few questions, I think two. One that kind of leads into the other, so maybe I can read out to you. So, yeah, I think one that was asked even before the talk started, so I think you have a fan who's wondering, what is the future of curve-based snarks compared to hash-based snarks? I was expecting this question, by the way. I mean, yeah, hash-based snarks, they are fast because you can construct them over smaller fields, so you can speed up things. But I still believe that curve-based snarks, they come with succinctness, so there is like a place for both. And today we see that, for example, for ZKVMs or ZKEVMs, they do a lot of stark proving, so hash-based SNARKs. But then at the end of the day, they compose it or they wrap it with a curve-based SNARK so that they can get Ethereum compatibility one and they can get success, which is like proofs are small. So I think, I believe both are to stay. Good. Then, so do you think recursive SNARK into STARK might present an interest to be post-quantum? Here, SNARK cannot be simulated by post-quantum computer. How SNARK and STARK benches, benchmarks? Okay, so let me try to understand the question. You can pose, yeah. So I think, yes, SNARKs, if we're saying that SNARKs are based on curves, which is not really the case, but I understand it like this. Well, if it is based on curves, it's not post-quantum. STARKs, well, if they are based on hashes, they are plausibly post-quantum. Composing both means that the protocol is not post-quantum. But yeah, if you want post-quantum resistance, then definitely anything that is hash-based. I mean, yeah, you can also talk about isogenies, because these are like curves-based. These are post-quantum, but I'm not aware of any isogeny-based snarks yet. And so I think then the last part of the question, how do they sort of benchmark against each other in terms of efficiency? Yeah, so it depends really on what baseline we're benchmarking against. So it really depends, but for example, if we are taking any... So SNARKs, they work over big fields defined by the elliptic curve. So if we define the statements over this field natively, then it's competitive. But in STOCKs, you can define them over any field. And for example, if you define them over binary field, like Binus, then you can do things like K-Chalk faster. So it really depends on the baseline. Nice. Okay. Good. Some more questions came in in the meantime. We have two minutes left, so we can go into it. Sure. How important is high two-addicity? Can we get away without it? Okay, yeah. So the 2-addicity is... So in ellipticals, we're working over this subgroup of prime order, and the 2-addicity means just this order minus 1 has to be divisible by a high power of 2, and it just means FFT-friendliness, because the best way to implement FFT is like radix to FFT. And for big circuits, then you definitely need this two-adicity. For small circuits, maybe you can get away with smoothness, like just some smooth integers dividing like p minus one. But yeah, for big circuit, like for example, I work on the linear ZKVM. We work on big circuits. So yeah, it's definitely a requirement for us. And why do you want to get away without it? I'm sorry, why? I'm just asking my follow-on, like from my own understanding, why do you want to get away without it? Like what problems does it introduce? Yeah, so it introduces the fact From my own understanding, why do you want to get away without it? What problems does it introduce? Yes, so it introduces the fact that you need a specific elliptic curve. For example, if I'm talking about Ethereum, so Ethereum curve, so the R-1 is divisible by high power of 2, but the P-1 is not. So if you want to do, for example, a recursion of Ethereum, it wouldn't work on the second layer. Yes, yes, Yes, of course. Good. Then last question while we have 30 seconds left. Why is it crucial for recursion to have two curves where one is prime and the other, one prime is the order of the other? Yes. So we express the statement of whatever we want to prove on the subgroup of the elliptic curve. And if we want to do a proof of a proof, we need to do the verification as a statement. But the verification uses these pairings, and pairings are defined over a different field. So if you want to do pairings in the subgroup, you need the field of the pairing to match the field of your subgroup so that computations are native. Otherwise you need to emulate non-native field arithmetic which is quite costly. I mean we do this but it's quite costly. But if you have native then the number of constraints or your proof generation will be way, way faster. Good. I see there are more questions, but we're actually out of time. Maybe you can catch him offline. But yeah, thank you very much. I'm thrilled with the amount of questions. Great. Thank you very much. Thank you.",
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731405600000,
- "slot_end": 1731407400000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/15MaGmHzAvHj765BvqDHs0ZxiiGevi3H9hscAvkCAGTc",
- "resources_slides": null,
- "speakers": [
- "youssef-el-housni"
- ]
+ "slot_start": 1731468600000,
+ "slot_end": 1731471300000,
+ "slot_roomId": "decompression-room",
+ "resources_presentation": "https://docs.google.com/presentation/d/16hER2e4hzqPjZrObAFmLsPIfyEkBHspMF-2HfxORQAg"
},
"vector": [
0,
@@ -263102,7 +262536,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -263380,7 +262813,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -263858,7 +263290,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -263920,7 +263351,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -264127,7 +263557,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -264136,8 +263565,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -264406,7 +263833,9 @@
0,
0,
0,
- 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -264419,6 +263848,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -264428,32 +263859,39 @@
},
{
"session": {
- "id": "embodiment-practice",
- "sourceId": "LNF8NE",
- "title": "Embodiment Practice",
- "description": "By master Zoe\r\n- Gentle guided stretches to connect with the body and open different energy channels\r\n- A blend of embodiment, asana, meditation, breathwork, tapping, and somatics to weave together mind, body, and soul\r\n\r\nNov 13 10:30 - 11:15",
- "track": "Entertainment",
- "type": "Mixed Formats",
- "expertise": "Beginner",
- "audience": "Hobby",
+ "id": "emilie-making-sure-eof-is-done-right",
+ "sourceId": "A9UWAY",
+ "title": "Emilie - Making sure EOF is done right",
+ "description": "We present Emilie. Emilie is designed to ensure the correct implementation of the EVM Object Format (EOF) by testing compilers and execution clients. It re-executes mainnet transactions using EOF bytecode instead of original bytecode, comparing results and performance with the original execution.\r\nEmilie tests interactions between EOF and legacy contracts using real data. It supports recompilation for Solidity and Vyper, enabling it to find bugs across compilers and execution clients.",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "EOF"
+ ],
+ "tags": [
+ "Core Protocol",
+ "ACD",
+ "Testing",
+ "eof",
+ "ACD",
+ "Core Protocol",
+ "Testing"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "hubert-ritzdorf"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731468600000,
- "slot_end": 1731471300000,
- "slot_roomId": "decompression-room",
- "resources_presentation": "https://docs.google.com/presentation/d/16hER2e4hzqPjZrObAFmLsPIfyEkBHspMF-2HfxORQAg"
+ "slot_start": 1731562800000,
+ "slot_end": 1731563400000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/17yJsWv6HioxijpCWnMnLMPeQFMTy_KMomUQHF2n1hS8"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -264741,6 +264179,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -265221,6 +264660,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -265441,6 +264881,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -265486,11 +264927,17 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -265755,28 +265202,21 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
2,
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0
@@ -265784,41 +265224,43 @@
},
{
"session": {
- "id": "emilie-making-sure-eof-is-done-right",
- "sourceId": "A9UWAY",
- "title": "Emilie - Making sure EOF is done right",
- "description": "We present Emilie. Emilie is designed to ensure the correct implementation of the EVM Object Format (EOF) by testing compilers and execution clients. It re-executes mainnet transactions using EOF bytecode instead of original bytecode, comparing results and performance with the original execution.\r\nEmilie tests interactions between EOF and legacy contracts using real data. It supports recompilation for Solidity and Vyper, enabling it to find bugs across compilers and execution clients.",
- "track": "Core Protocol",
- "type": "Lightning Talk",
+ "id": "empirical-analysis-of-amm-loss-versus-rebalancing-on-layer-2-chains",
+ "sourceId": "T8BXK3",
+ "title": "Empirical analysis of AMM loss versus rebalancing on layer 2 chains",
+ "description": "This talk presents an empirical analysis of Loss versus Rebalancing (LVR) on Arbitrum, Base and Ethereum. It compares the realised and theoretical LVR; along with the arbitrage profits from CEX-DEX/Perpetual; then further reveals whether the frequency of delta-hedging, the pool liquidity and the block time difference lead to better or worse LVR.",
+ "track": "Cryptoeconomics",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "EOF"
+ "loss versus rebalancing",
+ "cross-domain arbitrage"
],
"tags": [
- "Core Protocol",
- "ACD",
- "Testing",
- "eof",
- "ACD",
- "Core Protocol",
- "Testing"
+ "Layer 2s",
+ "Cross-L2",
+ "MEV",
+ "AMMs",
+ "cross-domain",
+ "arbitrage",
+ "AMMs",
+ "Cross-L2",
+ "Layer 2s",
+ "MEV"
],
"language": "en",
"speakers": [
- "hubert-ritzdorf"
+ "elaine-hu"
],
"eventId": "devcon-7",
- "slot_start": 1731562800000,
- "slot_end": 1731563400000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/17yJsWv6HioxijpCWnMnLMPeQFMTy_KMomUQHF2n1hS8"
+ "slot_start": 1731562200000,
+ "slot_end": 1731564000000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Y6GrE_61ZfJ2Mxu9xrE-xcG7WBCWmKg3qYPa5F0zL3s"
},
"vector": [
- 0,
- 0,
0,
0,
6,
@@ -266105,11 +265547,9 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -266572,6 +266012,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -266588,7 +266029,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -266636,6 +266076,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -266652,6 +266093,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -266768,6 +266210,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -266810,7 +266253,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -266856,14 +266298,13 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
2,
- 0,
+ 2,
0,
0,
0,
@@ -267134,8 +266575,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -267152,52 +266593,62 @@
},
{
"session": {
- "id": "empirical-analysis-of-amm-loss-versus-rebalancing-on-layer-2-chains",
- "sourceId": "T8BXK3",
- "title": "Empirical analysis of AMM loss versus rebalancing on layer 2 chains",
- "description": "This talk presents an empirical analysis of Loss versus Rebalancing (LVR) on Arbitrum, Base and Ethereum. It compares the realised and theoretical LVR; along with the arbitrage profits from CEX-DEX/Perpetual; then further reveals whether the frequency of delta-hedging, the pool liquidity and the block time difference lead to better or worse LVR.",
- "track": "Cryptoeconomics",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "id": "empower-the-ethereum-network-with-your-own-node",
+ "sourceId": "RAXURS",
+ "title": "Empower the Ethereum Network with your own node",
+ "description": "Stereum is an easy to use MIT-licensed Open Source GUI open-source Node Setup & Management Software.\r\nAfter a couple of clicks you have your hardware set up for \r\n1) Solo Staking (MEV)\r\n2) Distributed Validator Staking(Obol, SSV)\r\n3) running an Archive Node \r\n4) node operation of several protocols (SSV Network, CSM and Simple DVTM)\r\nWe want to make a workshop, where you can tryout a setup yourself and take time for your questions. dApps, testnet-mainnet switch and client-diversity supported!",
+ "track": "Usability",
+ "type": "Workshop",
+ "expertise": "Beginner",
+ "audience": "Stakers/Validators",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "loss versus rebalancing",
- "cross-domain arbitrage"
- ],
"tags": [
- "Layer 2s",
- "Cross-L2",
- "MEV",
- "AMMs",
- "cross-domain",
- "arbitrage",
- "AMMs",
- "Cross-L2",
- "Layer 2s",
- "MEV"
+ "Staking",
+ "Best Practices",
+ "Accessibility",
+ "network",
+ "access",
+ "Accessibility",
+ "Best Practices",
+ "Staking"
],
- "language": "en",
- "speakers": [
- "elaine-hu"
+ "keywords": [
+ "Ethereum Node",
+ "Tooling",
+ "Network Access"
],
+ "duration": 4470,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "cAsztMfLfF0",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67342cb69dbb7a90e1c1a7f6.vtt",
+ "transcript_text": " Good morning everybody. I'm Stefan Kobroth. I'm the founder of Styrium and RockLogic and we will do a workshop together to set up an Ethereum node with different kinds of services. First of all some facts about us. RockLogic was founded in 2012, not actually as a blockchain company but an IT infrastructure company, DevOps company. We develop Styrium since 2020. So already before the genesis of proof of stake of Styrium happened, we started with the development. We're an institutional node operator, so we use Styrium also for our own operations, which include the staking efforts in Lido. We already performed a couple of security audits for Stereo to ensure that everything is running fine and we don't overlook some major security vulnerabilities. We also won some awards. I guess the most recognizing, at least in Austria, is the Austrian Blockchain Award 2021. And this year we founded a separate company for this great product. And also this year we launched Styrium Plus, which is an addition to Styrium, a hosting service that you don't need to care anymore about where you get your own machine for Styrium. So some use cases for Styrium itself. Styrium is open source. Everybody can look at the source, of course. And everybody can use it in whatever way they want to. It's MIT licensed. It means you can also fork it, rebrand it, whatever you like to do with the source code. It's up to you. Some use cases, of course, are staking. We, as mentioned, use it for ourselves, for our own operations with Lido and other protocols. There are also protocol node operations for Oido and other protocols. There are also protocol node operations for OBL and SSV, so it's very easy with Styrium to set up a Lido CSM operator as well as OBL or SSV operators. Then it's also possible that you run your own clusters with OBL and SSV. In case you don't know, OBL and SSV are DVTs, distributed validator technologies, that help you spread one key, one validator key, over multiple servers to ensure more reliability, more resilience to technical issues or other issues that you might face. Of course, you can also use Stereo as an RPC node. Maybe some of you guys already use Infura or some other RPC provider, and you know that you're limited with them. But with your own node, you're basically just limited by the hardware you're putting Styrium onto. We have users that run arbitrage bots on it. We have users that run connector metamask on it. That's pretty easy and will be explained also later. Of course, you can start developing your own decentralized app with Styrium because you have the full range of RPC requests that you can use. As well, of course, as WebSocket. And of course, Stereo runs everything you want to. You're not limited to the stuff that we provide you. You can also come up with custom services that you integrate pretty easily. That will be also explained a little bit later on. As you may know, Ethereum has multiple clients. First of all, we have execution clients and consensus clients. Both clients are needed to ensure that you can run a full node or an archive node. We support most of the recent clients, most of the major clients. We also look always into some smaller clients, but up until right now, they were a little bit too unstable to integrate. And we want to make sure that the user has a seamless experience in running an Ethereum node. So how do you run an Ethereum node? First of all, you can run it on cloud or on your home PC or your office computer, wherever you want. Of course, with cloud, you have AWS, GCP, Hedgner and our new product, Serium Plus, of course, which makes it very easy to use with Sterium. With ARM, it's a little bit complicated. You could run a full node with Raspberry Pi 4, but it's a little bit slow, so I would not recommend it. If you want to use ARM, I would really recommend the OROC 5B or the Orange Pi 5. It's a much smoother experience, especially on mainnet. With x86 machines, generally you just choose a CPU with a benchmark over 20,000. For some that might sound a lot, but if there are some network issues, then you will be happy to have some more CPU power to actually deal with these issues. 60 gigabytes of memory are, in my opinion, a must to run on mainnet. below that it's it's already a pain two terabyte SSD I want to emphasize SSD here old HDDs they don't work well with with with notes also not with full notes like and especially not with archive notes two terabyte might be a little bit on the short side for the long run, as well as two less for some of the clients. We know that some clients don't prune very well, like delete all old data that they don't need anymore. If you want to be future-proof, then go for 3 or 4 terabytes, that's way better. But 2 terabytes should at least give you a head start and make sure Sorry, wrong button. Okay, then. Thank you very much. Welcome to David. Thank you very much. I'll take your offer. Thank you. Thank you, Stefan. Okay. As this is a beginner's workshop, we now want to go into the whole staking process. We want to walk you step by step through it because we have enough time. And, yeah, so the next point is staking with Serum Setup. So there are four overall steps you have to do to stake yourself. First of all, you have to have 32 ETH, but that you already know. Maybe that will change in the future, but at the moment it's 32. Then you have to create your validator keys with a C-trace. We will show you this today with a tool called Vacu. Then you should do your validator setup, so a full node run with a validator that you can do with STIRRUM, but there are other tools as well. Then afterwards, if you have a running setup, you should load up a validator key with the 32EVE and, of course, always should start with testnet if you're new to this stuff. And the fourth step is then afterwards enjoy the journey. Okay. So I try to emphasize the whole process again in a picture. So you create here the key. Then after you have a running setup, then in that key you give the withdrawal address where the 32EV will be sent back and where the attestation rewards and the syncom media rewards will also be sent in which wallet. So it's kind of safe after you load it up with the 32E, because if you ever exit your validator key, it will only go to that wallet. So, yeah, you're safe afterwards. Then you... Yeah, after that process, after you loaded up the key, you have some time to be... After you've deposited the 32 ETH, you have some time to be approved on mainnet. That's, I think, around seven days. And in the meantime, you can start to validate the client and set the fee recipient address. So that's another possibility to earn rewards. And there you get the fee recipient is a wallet where you get the block production rewards. Okay. So how now to create a validator key? You might be interested. There are different tools we will use today. Vagu. And maybe, yeah, as I will show you, you shouldn't do it because you should do it on an extra machine, best set up only for creating a key with no internet connection whatsoever. But for today, as we do it only for tests, I will show you on that. So, Wagyu is an open source tool I think you can easily find. As I said, if you're a beginner, you should use the testnet for staking. Holesky is really pleasant to use. And then, first of all, you need to create a new recovery phase. And as you see, the tool already warns me that the Internet is connected. So you should really emphasize on that. So you see, it's really easy to do. Just create a secret recovery phase. And then, like every C-Trace, you should write it down, put it in steel so that you can't lose it, and never ever share it with anyone except your wife. Okay. Takes up to 30 seconds or longer. Yeah. Okay, yeah. Could we? Oh, yeah. Someone already asked this. Would it be possible to just the lights in the room to make it a little bit? MARTIN SPLITTMANNKAMPFENGER THROUGH INTERPRETER 1 MARTIN SPLITTMANNKAMPFENGER THROUGH INTERPRETER 2 MARTIN SPLITTMANNKAMPFENGER THROUGH INTERPRETER 3 MARTIN SPLITTMANNKAMPFENGER THROUGH INTERPRETER 4 But maybe that's also securing the C-trace. Okay. Okay. After you have written it down, you have also here the option to copy it into a file. As I said, I wouldn't store it on any digital device. I would really craft it in paper or in steel. But I will copy it now for the ease of the process. Thank you. Thank you. Everybody? Yeah, I wouldn't now go back because then we have to do a next seed phase, but I think from now on we're good. Okay. So then you go next. It really asks you again if you backed it up. I'm sure that I'm lying. And then you have to confirm that you have the secret recovery phase. So this tool is really good. It really makes sure that you're safe. Now you can check it. And you can use your seed phrase for generating more than one key. What's the cool thing is you can also generate further key if you are in need on a later time. Just remember the seed phrase, put it in here again, and then you can say how much keys you already created and the number of much keys you already created and the number of new keys you have. So I set the password. And if you want a withdrawal address, you might want to take your own one. Perfect. Already some Holesky-Eth here. Okay. Take a password that is longer than eight characters. And remember it. Better write it maybe also down. So, and then you're done. Just have to say where to put the files. I will there and create them. And I should have created a folder. Okay. That might take some time. And in the meantime, yeah, we've done the setup. You can also see it in the slides. The QR code is shared, I think, afterwards. So there's the whole tutorial again and we're done with creating the validator key so the next thing is to do the setup the validator setup okay ah yes here no yes so I'm done Here. No? Yes. So I'm done. Yeah, you get two files. The one is the deposit file you will use to load up the validator key. I will show you or walk you through the process as well as there. Yeah, I walk you there. There we will use Launchpad for that later on. Okay, lights are... And now we are starting to use Ethereum and making our node setup. So what you need is a Ubuntu server machine that runs on the newest Ubuntu version, stable version. You might also use other Linux distributions, but it's's not tested so we can't guarantee you anything. So yeah then just give in to the credentials and if you if you give the credentials the first time there's this option to save it with the plus sign and connect. And of course first load down the STIRIUM launcher which you can find on our website or in the GitHub. So let's see.",
"eventId": "devcon-7",
- "slot_start": 1731562200000,
- "slot_end": 1731564000000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1Y6GrE_61ZfJ2Mxu9xrE-xcG7WBCWmKg3qYPa5F0zL3s"
+ "slot_start": 1731465900000,
+ "slot_end": 1731471300000,
+ "slot_roomId": "classroom-c",
+ "resources_presentation": "https://docs.google.com/presentation/d/1pvjBcm_guIMvayHy6vzCMwdxhLF_FviCoXJx10mrzT8",
+ "resources_slides": null,
+ "speakers": [
+ "stefan-kobrc",
+ "stereum-team",
+ "david-muhlbacher"
+ ]
},
"vector": [
0,
0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -267479,6 +266930,8 @@
0,
0,
6,
+ 6,
+ 6,
0,
0,
0,
@@ -267943,7 +267396,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -267968,6 +267420,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -267996,6 +267449,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -268007,7 +267461,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -268065,6 +267518,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -268141,11 +267595,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -268236,7 +267685,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -268502,17 +267950,17 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -268524,53 +267972,38 @@
},
{
"session": {
- "id": "empower-the-ethereum-network-with-your-own-node",
- "sourceId": "RAXURS",
- "title": "Empower the Ethereum Network with your own node",
- "description": "Stereum is an easy to use MIT-licensed Open Source GUI open-source Node Setup & Management Software.\r\nAfter a couple of clicks you have your hardware set up for \r\n1) Solo Staking (MEV)\r\n2) Distributed Validator Staking(Obol, SSV)\r\n3) running an Archive Node \r\n4) node operation of several protocols (SSV Network, CSM and Simple DVTM)\r\nWe want to make a workshop, where you can tryout a setup yourself and take time for your questions. dApps, testnet-mainnet switch and client-diversity supported!",
- "track": "Usability",
- "type": "Workshop",
+ "id": "empowering-a-safer-internet-community-driven-scam-reporting-and-prevention-in-thailand",
+ "sourceId": "FGUAQX",
+ "title": "Empowering a Safer Internet: community-driven scam reporting and prevention in Thailand\"",
+ "description": "In today’s digital age, user-driven solutions are vital for online safety. This talk explores Whoscall—a free mobile app trusted by over 17 million users globally, offering call and SMS identification, phishing site scanning, and personal data breach detection—and Thailand’s Scam Alert feature. Both initiatives empower users and promote public-private collaboration in scam prevention.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Stakers/Validators",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Staking",
- "Best Practices",
- "Accessibility",
- "network",
- "access",
- "Accessibility",
- "Best Practices",
- "Staking"
- ],
"keywords": [
- "Ethereum Node",
- "Tooling",
- "Network Access"
+ "Anti-Scam"
+ ],
+ "tags": [
+ "Public good",
+ "SEA",
+ "Security"
],
- "duration": 4470,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "cAsztMfLfF0",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67342cb69dbb7a90e1c1a7f6.vtt",
- "transcript_text": " Good morning everybody. I'm Stefan Kobroth. I'm the founder of Styrium and RockLogic and we will do a workshop together to set up an Ethereum node with different kinds of services. First of all some facts about us. RockLogic was founded in 2012, not actually as a blockchain company but an IT infrastructure company, DevOps company. We develop Styrium since 2020. So already before the genesis of proof of stake of Styrium happened, we started with the development. We're an institutional node operator, so we use Styrium also for our own operations, which include the staking efforts in Lido. We already performed a couple of security audits for Stereo to ensure that everything is running fine and we don't overlook some major security vulnerabilities. We also won some awards. I guess the most recognizing, at least in Austria, is the Austrian Blockchain Award 2021. And this year we founded a separate company for this great product. And also this year we launched Styrium Plus, which is an addition to Styrium, a hosting service that you don't need to care anymore about where you get your own machine for Styrium. So some use cases for Styrium itself. Styrium is open source. Everybody can look at the source, of course. And everybody can use it in whatever way they want to. It's MIT licensed. It means you can also fork it, rebrand it, whatever you like to do with the source code. It's up to you. Some use cases, of course, are staking. We, as mentioned, use it for ourselves, for our own operations with Lido and other protocols. There are also protocol node operations for Oido and other protocols. There are also protocol node operations for OBL and SSV, so it's very easy with Styrium to set up a Lido CSM operator as well as OBL or SSV operators. Then it's also possible that you run your own clusters with OBL and SSV. In case you don't know, OBL and SSV are DVTs, distributed validator technologies, that help you spread one key, one validator key, over multiple servers to ensure more reliability, more resilience to technical issues or other issues that you might face. Of course, you can also use Stereo as an RPC node. Maybe some of you guys already use Infura or some other RPC provider, and you know that you're limited with them. But with your own node, you're basically just limited by the hardware you're putting Styrium onto. We have users that run arbitrage bots on it. We have users that run connector metamask on it. That's pretty easy and will be explained also later. Of course, you can start developing your own decentralized app with Styrium because you have the full range of RPC requests that you can use. As well, of course, as WebSocket. And of course, Stereo runs everything you want to. You're not limited to the stuff that we provide you. You can also come up with custom services that you integrate pretty easily. That will be also explained a little bit later on. As you may know, Ethereum has multiple clients. First of all, we have execution clients and consensus clients. Both clients are needed to ensure that you can run a full node or an archive node. We support most of the recent clients, most of the major clients. We also look always into some smaller clients, but up until right now, they were a little bit too unstable to integrate. And we want to make sure that the user has a seamless experience in running an Ethereum node. So how do you run an Ethereum node? First of all, you can run it on cloud or on your home PC or your office computer, wherever you want. Of course, with cloud, you have AWS, GCP, Hedgner and our new product, Serium Plus, of course, which makes it very easy to use with Sterium. With ARM, it's a little bit complicated. You could run a full node with Raspberry Pi 4, but it's a little bit slow, so I would not recommend it. If you want to use ARM, I would really recommend the OROC 5B or the Orange Pi 5. It's a much smoother experience, especially on mainnet. With x86 machines, generally you just choose a CPU with a benchmark over 20,000. For some that might sound a lot, but if there are some network issues, then you will be happy to have some more CPU power to actually deal with these issues. 60 gigabytes of memory are, in my opinion, a must to run on mainnet. below that it's it's already a pain two terabyte SSD I want to emphasize SSD here old HDDs they don't work well with with with notes also not with full notes like and especially not with archive notes two terabyte might be a little bit on the short side for the long run, as well as two less for some of the clients. We know that some clients don't prune very well, like delete all old data that they don't need anymore. If you want to be future-proof, then go for 3 or 4 terabytes, that's way better. But 2 terabytes should at least give you a head start and make sure Sorry, wrong button. Okay, then. Thank you very much. Welcome to David. Thank you very much. I'll take your offer. Thank you. Thank you, Stefan. Okay. As this is a beginner's workshop, we now want to go into the whole staking process. We want to walk you step by step through it because we have enough time. And, yeah, so the next point is staking with Serum Setup. So there are four overall steps you have to do to stake yourself. First of all, you have to have 32 ETH, but that you already know. Maybe that will change in the future, but at the moment it's 32. Then you have to create your validator keys with a C-trace. We will show you this today with a tool called Vacu. Then you should do your validator setup, so a full node run with a validator that you can do with STIRRUM, but there are other tools as well. Then afterwards, if you have a running setup, you should load up a validator key with the 32EVE and, of course, always should start with testnet if you're new to this stuff. And the fourth step is then afterwards enjoy the journey. Okay. So I try to emphasize the whole process again in a picture. So you create here the key. Then after you have a running setup, then in that key you give the withdrawal address where the 32EV will be sent back and where the attestation rewards and the syncom media rewards will also be sent in which wallet. So it's kind of safe after you load it up with the 32E, because if you ever exit your validator key, it will only go to that wallet. So, yeah, you're safe afterwards. Then you... Yeah, after that process, after you loaded up the key, you have some time to be... After you've deposited the 32 ETH, you have some time to be approved on mainnet. That's, I think, around seven days. And in the meantime, you can start to validate the client and set the fee recipient address. So that's another possibility to earn rewards. And there you get the fee recipient is a wallet where you get the block production rewards. Okay. So how now to create a validator key? You might be interested. There are different tools we will use today. Vagu. And maybe, yeah, as I will show you, you shouldn't do it because you should do it on an extra machine, best set up only for creating a key with no internet connection whatsoever. But for today, as we do it only for tests, I will show you on that. So, Wagyu is an open source tool I think you can easily find. As I said, if you're a beginner, you should use the testnet for staking. Holesky is really pleasant to use. And then, first of all, you need to create a new recovery phase. And as you see, the tool already warns me that the Internet is connected. So you should really emphasize on that. So you see, it's really easy to do. Just create a secret recovery phase. And then, like every C-Trace, you should write it down, put it in steel so that you can't lose it, and never ever share it with anyone except your wife. Okay. Takes up to 30 seconds or longer. Yeah. Okay, yeah. Could we? Oh, yeah. Someone already asked this. Would it be possible to just the lights in the room to make it a little bit? MARTIN SPLITTMANNKAMPFENGER THROUGH INTERPRETER 1 MARTIN SPLITTMANNKAMPFENGER THROUGH INTERPRETER 2 MARTIN SPLITTMANNKAMPFENGER THROUGH INTERPRETER 3 MARTIN SPLITTMANNKAMPFENGER THROUGH INTERPRETER 4 But maybe that's also securing the C-trace. Okay. Okay. After you have written it down, you have also here the option to copy it into a file. As I said, I wouldn't store it on any digital device. I would really craft it in paper or in steel. But I will copy it now for the ease of the process. Thank you. Thank you. Everybody? Yeah, I wouldn't now go back because then we have to do a next seed phase, but I think from now on we're good. Okay. So then you go next. It really asks you again if you backed it up. I'm sure that I'm lying. And then you have to confirm that you have the secret recovery phase. So this tool is really good. It really makes sure that you're safe. Now you can check it. And you can use your seed phrase for generating more than one key. What's the cool thing is you can also generate further key if you are in need on a later time. Just remember the seed phrase, put it in here again, and then you can say how much keys you already created and the number of much keys you already created and the number of new keys you have. So I set the password. And if you want a withdrawal address, you might want to take your own one. Perfect. Already some Holesky-Eth here. Okay. Take a password that is longer than eight characters. And remember it. Better write it maybe also down. So, and then you're done. Just have to say where to put the files. I will there and create them. And I should have created a folder. Okay. That might take some time. And in the meantime, yeah, we've done the setup. You can also see it in the slides. The QR code is shared, I think, afterwards. So there's the whole tutorial again and we're done with creating the validator key so the next thing is to do the setup the validator setup okay ah yes here no yes so I'm done Here. No? Yes. So I'm done. Yeah, you get two files. The one is the deposit file you will use to load up the validator key. I will show you or walk you through the process as well as there. Yeah, I walk you there. There we will use Launchpad for that later on. Okay, lights are... And now we are starting to use Ethereum and making our node setup. So what you need is a Ubuntu server machine that runs on the newest Ubuntu version, stable version. You might also use other Linux distributions, but it's's not tested so we can't guarantee you anything. So yeah then just give in to the credentials and if you if you give the credentials the first time there's this option to save it with the plus sign and connect. And of course first load down the STIRIUM launcher which you can find on our website or in the GitHub. So let's see.",
- "eventId": "devcon-7",
- "slot_start": 1731465900000,
- "slot_end": 1731471300000,
- "slot_roomId": "classroom-c",
- "resources_presentation": "https://docs.google.com/presentation/d/1pvjBcm_guIMvayHy6vzCMwdxhLF_FviCoXJx10mrzT8",
- "resources_slides": null,
"speakers": [
- "stefan-kobrc",
- "stereum-team",
- "david-muhlbacher"
- ]
+ "michelle-shen"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731579600000,
+ "slot_end": 1731580200000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1PhodWX8WCiq6P9Vsm9h6TVZlVmdMbAjQkvyVws1MlFw"
},
"vector": [
+ 0,
+ 6,
+ 0,
0,
0,
0,
@@ -268579,7 +268012,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -268861,8 +268293,6 @@
0,
0,
0,
- 6,
- 6,
6,
0,
0,
@@ -269320,6 +268750,26 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -269354,7 +268804,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -269383,7 +268832,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -269452,7 +268900,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -269546,6 +268993,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -269619,30 +269070,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -269893,7 +269320,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -269901,45 +269327,43 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "empowering-a-safer-internet-community-driven-scam-reporting-and-prevention-in-thailand",
- "sourceId": "FGUAQX",
- "title": "Empowering a Safer Internet: community-driven scam reporting and prevention in Thailand\"",
- "description": "In today’s digital age, user-driven solutions are vital for online safety. This talk explores Whoscall—a free mobile app trusted by over 17 million users globally, offering call and SMS identification, phishing site scanning, and personal data breach detection—and Thailand’s Scam Alert feature. Both initiatives empower users and promote public-private collaboration in scam prevention.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "id": "empowering-users-how-ethereums-low-node-requirements-promote-true-decentralization-over-solana",
+ "sourceId": "QAJNMK",
+ "title": "Empowering Users: How Ethereum’s Low Node Requirements Promote True Decentralization Over Solana",
+ "description": "Nine years after Ethereum's launch, you can still run a node at home on commodity hardware, even low-powered devices like $185 ARM64 boards.\r\n\r\nWhy is this so important? Wouldn't Solana's approach, using more powerful hardware for higher speed and throughput, be better? We'll explore why home nodes matter for decentralization, credible neutrality, and global accessibility.\r\n\r\nWe'll also compare node requirements vs the Nakamoto coefficient as metrics for measuring decentralization.",
+ "track": "Core Protocol",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Stakers/Validators",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Anti-Scam"
- ],
+ "keywords": [],
"tags": [
- "Public good",
- "SEA",
- "Security"
+ "Decentralization",
+ "Home staking"
],
"language": "en",
"speakers": [
- "michelle-shen"
+ "diego-losada"
],
"eventId": "devcon-7",
- "slot_start": 1731579600000,
- "slot_end": 1731580200000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1PhodWX8WCiq6P9Vsm9h6TVZlVmdMbAjQkvyVws1MlFw"
+ "slot_start": 1731643200000,
+ "slot_end": 1731643800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/149MDCwjImcWRfdIwZw6lfpbIkNtiT4AFD60ebK9hnNQ"
},
"vector": [
0,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -270687,8 +270111,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -270772,6 +270194,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -270787,6 +270210,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -270796,7 +270220,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -270931,8 +270354,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -271257,8 +270678,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -271270,30 +270691,45 @@
},
{
"session": {
- "id": "empowering-users-how-ethereums-low-node-requirements-promote-true-decentralization-over-solana",
- "sourceId": "QAJNMK",
- "title": "Empowering Users: How Ethereum’s Low Node Requirements Promote True Decentralization Over Solana",
- "description": "Nine years after Ethereum's launch, you can still run a node at home on commodity hardware, even low-powered devices like $185 ARM64 boards.\r\n\r\nWhy is this so important? Wouldn't Solana's approach, using more powerful hardware for higher speed and throughput, be better? We'll explore why home nodes matter for decentralization, credible neutrality, and global accessibility.\r\n\r\nWe'll also compare node requirements vs the Nakamoto coefficient as metrics for measuring decentralization.",
+ "id": "encrypted-mempools-a-path-to-ethereum-l1",
+ "sourceId": "SGDDEX",
+ "title": "Encrypted Mempools: a path to Ethereum L1",
+ "description": "This talk will explore the future of encrypted mempools, paving the way to enshrinement on Ethereum L1. Starting from current designs such as Shutter and SUAVE, security assumptions and out-of-protocol infrastructure can be stripped away with cryptography including homomorphic encryption, VDFs, and delay encryption. These approaches would trustlessly bring front running protection and censorship resistance to the protocol.",
"track": "Core Protocol",
"type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Stakers/Validators",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
"tags": [
- "Decentralization",
- "Home staking"
+ "encryption",
+ "mempool",
+ "Censorship Resistance",
+ "Core Protocol",
+ "Cryptography"
],
- "language": "en",
- "speakers": [
- "diego-losada"
+ "keywords": [
+ "Encrypted",
+ "Mempool"
],
+ "duration": 565,
+ "language": "en",
+ "sources_swarmHash": "13fb566c3794a741fd8dff3d5d83fa04159a09104d886258558e6781631adaaa",
+ "sources_youtubeId": "mUoWwRoHrvk",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67341b699dbb7a90e15dfe1a.vtt",
+ "transcript_text": " Hello, my name is Mark and I work as an Ethereum core developer for Nethermind. Recently, I've been working on implementing the Shutter encrypted mempool in the Nethermind client. Today, I'll be giving a whirlwind tour of the encrypted mempool design space and sketching a path towards enshrinement on Ethereum L1. Let's start with how a transaction normally ends up on chain without an encrypted mempool. So the user gossips their transaction, in this case a swap from ETH to donut tokens, and eventually it reaches the proposer or builder for this slot. You can decide to include it in their block. What's the problem with this? The first one is front running. So the proposer or someone else is able to insert their own transactions ahead of the users, front running them. They know that the swap will increase the price of donut tokens, so they can buy up those tokens first and make a profit, while the user gets worse execution on their trade. They can then sell off the token afterwards to make this a sandwich attack. This can also be a problem in other applications, such as in an on-chain strategy game. Imagine you can see your opponent's moves and front-run them with your own. The other problem is censorship. This is when the proposer doesn't include the user's transaction at all. Encrypted mempools are a solution to this. So the user posts their transaction encrypted in a public constraint, and the proposer is required to include all transactions from the public constraint in a predefined order at the top of their block. We need one extra component for this, known as the keeper, whose job is to publish the public key and release the secret keys just in time for the proposer to decrypt and include the transactions. There's a spectrum of possible keeper designs, ranging from trusted to trustless. In my opinion, only the most trustless of these will be suitable for the high standards of L1. On one end, we could have a trusted party with access to the secret keys. To improve on this, we could have the secret keys be stored inside a secure enclave, such as Intel SGX. This is what Suave does. With a threshold encrypted mempool, such as Shutter, we fragment the master secret key between a decentralized committee of keepers, requiring a threshold of two-thirds of them to come together to reconstruct the secret keys. Finally, we have delay encryption, where to reveal the secret keys, you have to evaluate a sequential function, which will take a certain amount of time. This is a relatively weak security assumption that everyone is able to evaluate this function at a similar speed, which can be achieved when specialized hardware is widely available. And I think this approach will be suitable for L1 enshrinement in the future. Now let's consider the design of this public constraint. So this constraint should be available to everyone to download, and its construction should be as permissionless as possible, so any user can add encrypted transactions to this public constraint. One approach is users posting their encrypted transactions to cool data. This is quite permissionless, but cool data can be expensive. Another approach is users sending their encrypted transactions to the proposer, who then constructs the constraint and posts it to blobs but this is more permissioned and there are other approaches here so we could imagine a random subset of validators constructing this public commitment and there's quite a lot of overlap here with inclusion this designs unfortunately in the worst case we can never be completely permissionless. Whoever has power to decide which transactions go into this public constraint could, for example, demand proof of OFAT compliance. However, assuming there is some legal protection for using encryption and encrypted mempools become the default, it's unlikely this would be a problem. So there are different approaches to ordering. I think priority fee ordering seems like a reasonable solution. In the future, once the cryptography is more matured, we might be able to do more advanced block building strategies using homomorphic encryption. Using this, we can perform encryption, sorry, perform ordering on the transactions while they are still encrypted, replicating the functionality of secure enclave designs. So how are we going to enforce proposals to include a transaction? We want to make them choose between including all of the transactions in the correct order at the top of the block, or all of them being invalidated so that the proposal would lose out on all of those tips. There are two different approaches here. We could enshrine into the protocol, so we tie the block validity to correct inclusion, or we could have an out-of-protocol solution, so we check for correct inclusion with a smart contract. In the long term, enshrinement would be preferable, but until then, we'll have out-of-protocol solutions. We've proposed EIP-7793, which is a relatively minimal change that will support these outer protocol memples to check for correct inclusion. And this allows a smart contract to tell where in the block is being executed. The final thing to consider is hiding transaction metadata. So when the user broadcasts their transaction, they can leak information such as timestamp, IP address, and size. We don't have time to cover this, but there are various approaches that can be used to hide this information. Thank you for listening. Thank you, Mark. Thank you for the session. Do you have questions for... Oh, wow. Interesting. Okay, I saw your hand first. I have one question. Do your approach go into as the overhead to the process to include the transaction into the block? Actually, you have to do everything in the rank of the block time to make sure that, yeah. I think there's relatively minimal overhead. So the user encrypts their transactions, and I guess it would add one slot of latency. So with Shutter, when we use cool data, we're going to have one transaction where we post, and there can also be an overhead in terms of gas fees for this post. And then after that, then we just have to decrypt and include that transaction. You mentioned the MEVs, it's all about an deterministic order of transaction. But then do you think the encrypt mempool is something very overkill for this problem? I don't think it's overkill really. I mean, yeah, we can't necessarily eliminate MEV entirely, but this does give us some front-running protection. Next question? Okay, here. Are there situations where an out-of-protocol mempool cannot protect against front-running? For example, if there's a chain reorganization, you have the old block, then you could front-run at the next block for the next block, right? So, I mean, yeah, so these... Yeah, I think there are some situations. I mean, with our protocol solutions such as Shutter, like, the validators have to register beforehand so you know, like, which proposers are signed up to use the out-of-protocol solution. And the keys would only be released in these cases. If the proposer doesn't include the transactions at all, then there's a chance they could be front run in the next one. But that's why we need this. We tie the block validity of the transactions to that slot, so no one could then later include these transactions. But you have potentially leaked some information about your transactions. With Shutter, currently, currently proposes trusted, right? Yeah, at the moment. But I'd say this is like just a step towards improving so you can remove these trust assumptions. Do you have one more question? Last question? Okay. Last question? Okay. Go here. Yeah, so from the user experience, front-end user experience point of view, how is this encrypted mempool superior to the flashbots in terms of, say, avoiding the sandwich attacks? Yeah. I'd say from the user experience perspective there's not really a difference it just depends on your own personal like trust model so they said sort of flashbots protect for example is like um i don't have the slides okay so it was like the most trusted approach on my thing whereas whereas we can progressively move to more trusted solutions so that you don't have to trust Flashbots to do this. All right. Thanks so much, Mark, for this session. If you have more questions, please come meet Mark and then get to deep dive. Thank you so much. Let's give a hands-off applause for Mark. Thank you.",
"eventId": "devcon-7",
- "slot_start": 1731643200000,
- "slot_end": 1731643800000,
+ "slot_start": 1731466500000,
+ "slot_end": 1731467100000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/149MDCwjImcWRfdIwZw6lfpbIkNtiT4AFD60ebK9hnNQ"
+ "resources_presentation": "https://docs.google.com/presentation/d/1lvMpzBomZ6dNVchh_7lRcXyFGQ2an1s7f3t0tDgzR2E",
+ "resources_slides": null,
+ "speakers": [
+ "marc-harvey-hill"
+ ]
},
"vector": [
0,
@@ -272058,11 +271494,13 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -272134,11 +271572,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -272150,7 +271583,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -272197,6 +271629,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -272344,6 +271777,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -272607,6 +272042,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -272619,9 +272055,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -272631,59 +272064,48 @@
},
{
"session": {
- "id": "encrypted-mempools-a-path-to-ethereum-l1",
- "sourceId": "SGDDEX",
- "title": "Encrypted Mempools: a path to Ethereum L1",
- "description": "This talk will explore the future of encrypted mempools, paving the way to enshrinement on Ethereum L1. Starting from current designs such as Shutter and SUAVE, security assumptions and out-of-protocol infrastructure can be stripped away with cryptography including homomorphic encryption, VDFs, and delay encryption. These approaches would trustlessly bring front running protection and censorship resistance to the protocol.",
- "track": "Core Protocol",
- "type": "Lightning Talk",
+ "id": "end-to-end-internet-games",
+ "sourceId": "EZ9T33",
+ "title": "End-to-end internet games",
+ "description": "For the past 1.5 years, I've been building fully onchain games–games where the entire state is onchain for some reason (have launched 7!). \r\n\r\nThere is lots of cryptographic data floating around the internet. New primitives are allowing all this data to be interoperable with each other... and even verifiable on-chain. \r\n\r\nI'll discuss some of this tech (tls notary, app attest, zkml, etc.) and discuss what new wild games we can build with them.",
+ "track": "Applied Cryptography",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "encryption",
- "mempool",
- "Censorship Resistance",
- "Core Protocol",
- "Cryptography"
- ],
"keywords": [
- "Encrypted",
- "Mempool"
+ "ZK",
+ "Programmable cryptography",
+ "onchain games"
+ ],
+ "tags": [
+ "Gaming",
+ "Mechanism design",
+ "Mobile"
],
- "duration": 565,
"language": "en",
- "sources_swarmHash": "13fb566c3794a741fd8dff3d5d83fa04159a09104d886258558e6781631adaaa",
- "sources_youtubeId": "mUoWwRoHrvk",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67341b699dbb7a90e15dfe1a.vtt",
- "transcript_text": " Hello, my name is Mark and I work as an Ethereum core developer for Nethermind. Recently, I've been working on implementing the Shutter encrypted mempool in the Nethermind client. Today, I'll be giving a whirlwind tour of the encrypted mempool design space and sketching a path towards enshrinement on Ethereum L1. Let's start with how a transaction normally ends up on chain without an encrypted mempool. So the user gossips their transaction, in this case a swap from ETH to donut tokens, and eventually it reaches the proposer or builder for this slot. You can decide to include it in their block. What's the problem with this? The first one is front running. So the proposer or someone else is able to insert their own transactions ahead of the users, front running them. They know that the swap will increase the price of donut tokens, so they can buy up those tokens first and make a profit, while the user gets worse execution on their trade. They can then sell off the token afterwards to make this a sandwich attack. This can also be a problem in other applications, such as in an on-chain strategy game. Imagine you can see your opponent's moves and front-run them with your own. The other problem is censorship. This is when the proposer doesn't include the user's transaction at all. Encrypted mempools are a solution to this. So the user posts their transaction encrypted in a public constraint, and the proposer is required to include all transactions from the public constraint in a predefined order at the top of their block. We need one extra component for this, known as the keeper, whose job is to publish the public key and release the secret keys just in time for the proposer to decrypt and include the transactions. There's a spectrum of possible keeper designs, ranging from trusted to trustless. In my opinion, only the most trustless of these will be suitable for the high standards of L1. On one end, we could have a trusted party with access to the secret keys. To improve on this, we could have the secret keys be stored inside a secure enclave, such as Intel SGX. This is what Suave does. With a threshold encrypted mempool, such as Shutter, we fragment the master secret key between a decentralized committee of keepers, requiring a threshold of two-thirds of them to come together to reconstruct the secret keys. Finally, we have delay encryption, where to reveal the secret keys, you have to evaluate a sequential function, which will take a certain amount of time. This is a relatively weak security assumption that everyone is able to evaluate this function at a similar speed, which can be achieved when specialized hardware is widely available. And I think this approach will be suitable for L1 enshrinement in the future. Now let's consider the design of this public constraint. So this constraint should be available to everyone to download, and its construction should be as permissionless as possible, so any user can add encrypted transactions to this public constraint. One approach is users posting their encrypted transactions to cool data. This is quite permissionless, but cool data can be expensive. Another approach is users sending their encrypted transactions to the proposer, who then constructs the constraint and posts it to blobs but this is more permissioned and there are other approaches here so we could imagine a random subset of validators constructing this public commitment and there's quite a lot of overlap here with inclusion this designs unfortunately in the worst case we can never be completely permissionless. Whoever has power to decide which transactions go into this public constraint could, for example, demand proof of OFAT compliance. However, assuming there is some legal protection for using encryption and encrypted mempools become the default, it's unlikely this would be a problem. So there are different approaches to ordering. I think priority fee ordering seems like a reasonable solution. In the future, once the cryptography is more matured, we might be able to do more advanced block building strategies using homomorphic encryption. Using this, we can perform encryption, sorry, perform ordering on the transactions while they are still encrypted, replicating the functionality of secure enclave designs. So how are we going to enforce proposals to include a transaction? We want to make them choose between including all of the transactions in the correct order at the top of the block, or all of them being invalidated so that the proposal would lose out on all of those tips. There are two different approaches here. We could enshrine into the protocol, so we tie the block validity to correct inclusion, or we could have an out-of-protocol solution, so we check for correct inclusion with a smart contract. In the long term, enshrinement would be preferable, but until then, we'll have out-of-protocol solutions. We've proposed EIP-7793, which is a relatively minimal change that will support these outer protocol memples to check for correct inclusion. And this allows a smart contract to tell where in the block is being executed. The final thing to consider is hiding transaction metadata. So when the user broadcasts their transaction, they can leak information such as timestamp, IP address, and size. We don't have time to cover this, but there are various approaches that can be used to hide this information. Thank you for listening. Thank you, Mark. Thank you for the session. Do you have questions for... Oh, wow. Interesting. Okay, I saw your hand first. I have one question. Do your approach go into as the overhead to the process to include the transaction into the block? Actually, you have to do everything in the rank of the block time to make sure that, yeah. I think there's relatively minimal overhead. So the user encrypts their transactions, and I guess it would add one slot of latency. So with Shutter, when we use cool data, we're going to have one transaction where we post, and there can also be an overhead in terms of gas fees for this post. And then after that, then we just have to decrypt and include that transaction. You mentioned the MEVs, it's all about an deterministic order of transaction. But then do you think the encrypt mempool is something very overkill for this problem? I don't think it's overkill really. I mean, yeah, we can't necessarily eliminate MEV entirely, but this does give us some front-running protection. Next question? Okay, here. Are there situations where an out-of-protocol mempool cannot protect against front-running? For example, if there's a chain reorganization, you have the old block, then you could front-run at the next block for the next block, right? So, I mean, yeah, so these... Yeah, I think there are some situations. I mean, with our protocol solutions such as Shutter, like, the validators have to register beforehand so you know, like, which proposers are signed up to use the out-of-protocol solution. And the keys would only be released in these cases. If the proposer doesn't include the transactions at all, then there's a chance they could be front run in the next one. But that's why we need this. We tie the block validity of the transactions to that slot, so no one could then later include these transactions. But you have potentially leaked some information about your transactions. With Shutter, currently, currently proposes trusted, right? Yeah, at the moment. But I'd say this is like just a step towards improving so you can remove these trust assumptions. Do you have one more question? Last question? Okay. Last question? Okay. Go here. Yeah, so from the user experience, front-end user experience point of view, how is this encrypted mempool superior to the flashbots in terms of, say, avoiding the sandwich attacks? Yeah. I'd say from the user experience perspective there's not really a difference it just depends on your own personal like trust model so they said sort of flashbots protect for example is like um i don't have the slides okay so it was like the most trusted approach on my thing whereas whereas we can progressively move to more trusted solutions so that you don't have to trust Flashbots to do this. All right. Thanks so much, Mark, for this session. If you have more questions, please come meet Mark and then get to deep dive. Thank you so much. Let's give a hands-off applause for Mark. Thank you.",
- "eventId": "devcon-7",
- "slot_start": 1731466500000,
- "slot_end": 1731467100000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1lvMpzBomZ6dNVchh_7lRcXyFGQ2an1s7f3t0tDgzR2E",
- "resources_slides": null,
"speakers": [
- "marc-harvey-hill"
- ]
+ "small-brain"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731477600000,
+ "slot_end": 1731479400000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1SKERFupONxE6JOQvDC21CI1lz62VYcj5ZdZOGlXcWOg"
},
"vector": [
0,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -272814,6 +272236,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -272967,7 +272390,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -273429,6 +272851,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -273437,15 +272860,14 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -273533,6 +272955,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -273572,7 +272995,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -273721,8 +273143,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -273989,7 +273409,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -274002,40 +273421,31 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "end-to-end-internet-games",
- "sourceId": "EZ9T33",
- "title": "End-to-end internet games",
- "description": "For the past 1.5 years, I've been building fully onchain games–games where the entire state is onchain for some reason (have launched 7!). \r\n\r\nThere is lots of cryptographic data floating around the internet. New primitives are allowing all this data to be interoperable with each other... and even verifiable on-chain. \r\n\r\nI'll discuss some of this tech (tls notary, app attest, zkml, etc.) and discuss what new wild games we can build with them.",
- "track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Intermediate",
+ "id": "energy-renewal-sound-healing",
+ "sourceId": "7DEDKP",
+ "title": "Energy Renewal (Sound Healing)",
+ "description": "By master Ice \r\nThis session helps you rest deeply, reset your energy, and find inner peace.\r\n- Recharge and relax with gentle sounds of gongs and bowls\r\n- a short guided meditation. \r\n\r\nNov 14 10:30 -11:15",
+ "track": "Entertainment",
+ "type": "Mixed Formats",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "ZK",
- "Programmable cryptography",
- "onchain games"
- ],
- "tags": [
- "Gaming",
- "Mechanism design",
- "Mobile"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "small-brain"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731477600000,
- "slot_end": 1731479400000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1SKERFupONxE6JOQvDC21CI1lz62VYcj5ZdZOGlXcWOg"
+ "slot_start": 1731555000000,
+ "slot_end": 1731557700000,
+ "slot_roomId": "decompression-room",
+ "resources_presentation": "https://docs.google.com/presentation/d/1FvG19MBxNr-yTjRDpb3Z4gWrJzfSxAeauH5sxykoiLg"
},
"vector": [
0,
@@ -274047,7 +273457,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -274180,7 +273589,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -274797,7 +274205,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -274813,7 +274220,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -274901,22 +274307,24 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -275354,7 +274762,6 @@
2,
0,
0,
- 0,
2,
0,
0,
@@ -275373,32 +274780,37 @@
},
{
"session": {
- "id": "energy-renewal-sound-healing",
- "sourceId": "7DEDKP",
- "title": "Energy Renewal (Sound Healing)",
- "description": "By master Ice \r\nThis session helps you rest deeply, reset your energy, and find inner peace.\r\n- Recharge and relax with gentle sounds of gongs and bowls\r\n- a short guided meditation. \r\n\r\nNov 14 10:30 -11:15",
- "track": "Entertainment",
- "type": "Mixed Formats",
- "expertise": "",
+ "id": "enhancing-ethereum-p2p-network-security-through-fuzzing",
+ "sourceId": "7SR77E",
+ "title": "Enhancing Ethereum P2P Network Security through Fuzzing",
+ "description": "Security is a big deal for Ethereum's p2p network. We think fuzzing is a great way to make it more secure. We developed a time-series-based fuzz testing tool for the Ethereum network layer. In this tool, we integrated mutation mechanisms and seed selection algorithms, and introduced a new time-series feedback model. Using this tool, we can spot and fix existing vulnerabilities while also spotting new risks.",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Fuzzing",
+ "p2p network"
+ ],
+ "tags": [
+ "network",
+ "p2p"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "tim-fan",
+ "sun-haochen",
+ "fudong-wu"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731555000000,
- "slot_end": 1731557700000,
- "slot_roomId": "decompression-room",
- "resources_presentation": "https://docs.google.com/presentation/d/1FvG19MBxNr-yTjRDpb3Z4gWrJzfSxAeauH5sxykoiLg"
+ "slot_start": 1731571200000,
+ "slot_end": 1731571800000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1B-0SsGH9Jbgo3njphxqoa7CInPi0Ftq_r5Ivuuvi8zg"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -275694,6 +275106,9 @@
0,
0,
0,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -276233,6 +275648,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -276442,10 +275858,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -276711,6 +276124,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -276729,41 +276143,51 @@
},
{
"session": {
- "id": "enhancing-ethereum-p2p-network-security-through-fuzzing",
- "sourceId": "7SR77E",
- "title": "Enhancing Ethereum P2P Network Security through Fuzzing",
- "description": "Security is a big deal for Ethereum's p2p network. We think fuzzing is a great way to make it more secure. We developed a time-series-based fuzz testing tool for the Ethereum network layer. In this tool, we integrated mutation mechanisms and seed selection algorithms, and introduced a new time-series feedback model. Using this tool, we can spot and fix existing vulnerabilities while also spotting new risks.",
- "track": "Core Protocol",
+ "id": "ens-war-stories-securing-web3-from-web2-based-attacks",
+ "sourceId": "P9U9Q3",
+ "title": "ENS War Stories: Securing Web3 from Web2-Based Attacks",
+ "description": "Web3 is not an island. Every day, threat actors try to exploit web2 domains to target web3 entities. This talk recounts ENS' war stories / lessons of battling threats in the DNS, including:\r\n- Detecting early-stage attacks on web3 entities in the DNS\r\n- How we unraveled a campaign of over 2,500+ web2 domains targeting web3 and defi entities \r\n- Legal and technical remedies to combat web2-based threats (and their limitations)\r\n- Why the ecosystem must come together to share intel and resources",
+ "track": "Security",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Fuzzing",
- "p2p network"
- ],
"tags": [
- "network",
- "p2p"
+ "Collective Intelligence",
+ "Security",
+ "Best Practices",
+ "user",
+ "safety",
+ "Best Practices",
+ "Collective Intelligence",
+ "Security"
],
- "language": "en",
- "speakers": [
- "tim-fan",
- "sun-haochen",
- "fudong-wu"
+ "keywords": [
+ "threat actors",
+ "legal process",
+ "user safety"
],
+ "duration": 781,
+ "language": "en",
+ "sources_swarmHash": "ddf9a9beb6a6cc606ece80ac2cfa5b7ea1dc15ed7e74f90748997b8a953b8574",
+ "sources_youtubeId": "ht_Szqvtx8w",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731571200000,
- "slot_end": 1731571800000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1B-0SsGH9Jbgo3njphxqoa7CInPi0Ftq_r5Ivuuvi8zg"
+ "slot_start": 1731389400000,
+ "slot_end": 1731390000000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1TPTt3DvIJCvQfAzoDGb3Ea32KlVjG7UCxB3UUz4JC4I",
+ "resources_slides": null,
+ "speakers": [
+ "alexander-urbelis"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -277056,15 +276480,14 @@
0,
0,
0,
- 6,
- 6,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -277514,6 +276937,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -277544,8 +276968,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -277600,7 +277026,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -277812,7 +277237,7 @@
0,
0,
2,
- 0,
+ 2,
0,
0,
0,
@@ -278077,12 +277502,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -278095,52 +277520,39 @@
},
{
"session": {
- "id": "ens-war-stories-securing-web3-from-web2-based-attacks",
- "sourceId": "P9U9Q3",
- "title": "ENS War Stories: Securing Web3 from Web2-Based Attacks",
- "description": "Web3 is not an island. Every day, threat actors try to exploit web2 domains to target web3 entities. This talk recounts ENS' war stories / lessons of battling threats in the DNS, including:\r\n- Detecting early-stage attacks on web3 entities in the DNS\r\n- How we unraveled a campaign of over 2,500+ web2 domains targeting web3 and defi entities \r\n- Legal and technical remedies to combat web2-based threats (and their limitations)\r\n- Why the ecosystem must come together to share intel and resources",
- "track": "Security",
+ "id": "ensuring-data-availability-in-l2s",
+ "sourceId": "SCUHA7",
+ "title": "Ensuring Data Availability in L2s",
+ "description": "The talk explores the risks associated with data availability (DA) providers in L2s, highlighting the necessary security guarantees of DA layers. It covers economic security considerations, security properties of DA attestations, and fraud detection mechanisms against data withholding attacks. The goal is to guide L2 users in understanding the different risk profiles of DA providers and assist developers and researchers in enhancing the security and functionality of L2 solutions.",
+ "track": "Layer 2",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
+ "keywords": [
+ "Risks"
+ ],
"tags": [
- "Collective Intelligence",
+ "Layer 2s",
+ "Data Availability",
"Security",
- "Best Practices",
- "user",
- "safety",
- "Best Practices",
- "Collective Intelligence",
+ "risk",
+ "Data Availability",
+ "Layer 2s",
"Security"
],
- "keywords": [
- "threat actors",
- "legal process",
- "user safety"
- ],
- "duration": 781,
"language": "en",
- "sources_swarmHash": "ddf9a9beb6a6cc606ece80ac2cfa5b7ea1dc15ed7e74f90748997b8a953b8574",
- "sources_youtubeId": "ht_Szqvtx8w",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731389400000,
- "slot_end": 1731390000000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1TPTt3DvIJCvQfAzoDGb3Ea32KlVjG7UCxB3UUz4JC4I",
- "resources_slides": null,
"speakers": [
- "alexander-urbelis"
- ]
+ "vincenzo-furcillo"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731654600000,
+ "slot_end": 1731655200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1fP4Av0dDJM1g4BBb6EB2lsaWqOTPmZK7RkZvBv_vs-w"
},
"vector": [
- 6,
0,
0,
0,
@@ -278148,6 +277560,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -278889,10 +278302,33 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -278923,9 +278359,16 @@
0,
0,
0,
- 2,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
2,
0,
0,
@@ -279160,6 +278603,30 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -279192,8 +278659,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -279398,10 +278863,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -279413,11 +278880,62 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "ensuring-privacy-in-digital-identity-to-prevent-a-dystopian-crisis",
+ "sourceId": "TZQYGY",
+ "title": "Ensuring Privacy in Digital Identity to Prevent a Dystopian Crisis",
+ "description": "This talk will explore introducing a method for privacy-preserving proof of user uniqueness in contexts like elections using DIDs, ZK, and VCs for verifying credentials without revealing unique identifiers while ensuring compatibility with multiple trust sources. This enables self-sovereign digital identity, allowing selective disclosure of verified credentials while protecting personal data, supporting privacy-preserving KYC, sybil resistance, compliant access to financial services, and more.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "tags": [
+ "Identity",
+ "Zero-Knowledge",
+ "Security",
+ "zk",
+ "proof",
+ "Identity",
+ "Security",
+ "Zero-Knowledge"
+ ],
+ "keywords": [
+ "Zk",
+ "Proof"
+ ],
+ "duration": 1426,
+ "language": "en",
+ "sources_swarmHash": "27893580368e8396780c9f103b3d94703c4ab1700db60ed5816b3334de7aff27",
+ "sources_youtubeId": "6EJBsHydyVU",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733207e3a168eb53546fce2.vtt",
+ "transcript_text": " Hello everybody, I'm Jordi Bailina, I'm Sasha from PrivatID. What's digital identity? To make it easy, digital identity is when you sign into a page, actually you're using your digital identity currently digital identity is Controlled by very few corporations your Facebook Twitter and so on just a side note Here in the web 3 means not even governed by governments I mean governments here could be a good allies to implement self-sovereign identity because probably governments they don't want to give the identity to these big corporations so it's very far it's fragmented I mean it's not very fragmented but I mean there is four five four five six seven big corporations that holds most of the people's identity and this from in addition and other things this gives us a really bad UX. I mean, I'm sure that maybe not here, but a lot of users have problems with passwords, and managing passwords, managing connections, emails, and all this kind of digital identity. So when we go to Web 3 and we are building dApps, actually we need identity too. I mean, we have the two exceptions. I mean, when you are transferring funds, maybe you don't need an identity. You just, well, you have some sort of identity, which is an account, but you don't really need identity. But if you want to do any other application, I don't know, voting, or you want to do, connect to a DAO or something. You will need some sort of login. You need some sort of identity. So we need identity in the Web3. And when we go to identity in the Web3, we may end up doing very much the same. If this is controlled by very few corporations, then what is happening is that it's even more fragmented and the UX is even worse. And not only that I mean the digit when we go to the center lights there are other risks and other important things that are happening of course we have the the privacy thing if we are publishing data this latter can be leakage easily and there are a lot of challenge that we need to solve on that. So how this solution needs to be? Of course, it needs to be self-sovereign. I mean, it needs to be decentralized. Each one needs to hold their own identity. And you are kind of a server of your identity. I mean, you are the identity. The protocol privacy needs to be by default and by design and by design in privacy needs to be here is where zero knowledge is important I mean the centralized identity without zero knowledge is impossible to make here I want to do an a note and is that the zero knowledge technology has been evolved a lot if you in the last in the last years if you, if you just go back three years ago, it was difficult to build identity systems because you end up using your own cryptography, you end up using, I mean, you had to do identity in a specific way so that you can apply zero knowledge. Currently, the zero knowledge technology, and thank you to all these layer tools and all this evolution that happens in the last year, it's much more powerful, much more faster, and it's perfectly possible to use normal cryptography. That means that you can use current attestations, I mean, the signatures of the governments, the signatures of the organizations that are already happening so a lot of attestations real attestations that are actually happening you can use them in zero knowledge you can build these decentralized database of that is attestation it's a single database where everybody just share such as just have access to a small part of that and then you can single source of truth and then you can prove things around that and finally of course this needs to be a open standard simple standard it will not come for big corporations it will come from the roots it will come from the like TCP IP I mean this needs to be something that should be simple so as an example of hope to connect this identity to these signatures, to these attestations that already happen in the world, I'm going to give the word to Sasha that will explain the work that we are doing in Privado ID. Sasha. Thank you. Thank you, Jordi. So, yeah, what's Privado ID? Privado ID is a self-sovereign identity solution, but also it's a middleware. It's an infrastructure so that you are able to build your own applications that have identity, that can work on different chains, multiple devices. And it's based on industry standards. It's based on W3C, DADs, and verifiable credentials. So it's an interoperable system that you're able to use and build on top of it. And also it's powered by zero knowledge proofs. So whenever you are using it, you're not sharing your actual data. You're sharing only proof that you're eligible to do something, like you're over 18 to purchase liquor in the store, yeah? Without providing whole document, without sharing your picture, without sharing your actual date of birth, your passport number, and so on. And key features that we have is that we are unifying this fragmented identity. We are bringing all different chains together, we are making it work on different multiple devices at the same time. And also, we are unifying Web2 and Web3 systems. So it's usable on the apps and on your regular applications and also on regular stores where you would go and buy things off-chain, offline. of chain offline and very important that for many things you need to do it only once like if you go and ask you I see you would do it only once then your credentials your data would be stored on your device under your control, and you would be sharing some pieces of it on request. You would be sharing just proofs, for example, that you're over 18, as I said, or maybe for some cases you would be selectively disclosing some data. Maybe it would be, for example, seat number in your ticket credential, let's say. Yeah, something like that. And we have two other very important features and very useful. One is privacy-preserving proof of uniqueness. And another, decentralized trustless issuance, where a smart contract is issuing you credentials. So that's why it could be trustless in terms that you are not trusting any specific centralized authority to issue you credential. You can do it on-chain in a decentralized manner, but also it could be done in privacy-preserving manner. So how is this proof of uniqueness working that we have? It's based on credentials. It could be different kinds of credentials. It could be biometrical data, yeah? But also it could be like phone number or credential that you have from your employer, that you are employee. And then you can use it to do, for example, voting in a company anonymous survey without disclosing who you are and without doing your iris scan to prove that you're unique, employer already knows that you're unique. It can control this data and issue credential. And then you are able to use it to prove uniqueness without disclosing who you actually are. And do specific action only once, like voting. And it's not only limited by credential, so you can use it on a specific credential for a specific use case, but also we have a special way to distinguish between different sessions even inside one application for example if you are doing multiple votings um or multiple surveys give a different context for the user and nullifier, your unique identifier for this purpose would be different between each session so that you would be anonymous, it would not not be possible to track who is actually voting between these different sessions. And as I said, there is different use cases. You can use it even for nationwide voting. For example, it could be based on a biometrical document like AdHardCard, and then you would prove that you're unique and you're eligible to vote and count this vote only once. And decentralized trustless issuance is a feature that allows you to do this in a privacy-preserving manner so that even there is no centralized issuer that knows who you are, so that issuer would be able to track who is acting and possibly de-anonymize you. So now I will show you how it works. And first demo is just a simple, very, very simple application where you are able to prove that your ownership of Ethereum address. So you would receive a credential that you are owner of Ethereum address. So what you need to do is actually you're just authenticating to the system, and then you send a transaction, and that's it. Credential is issued. Data was already on chain, so nothing needs to be additionally proven. So, it's very simple. And voila, you have a credential. In the same way, we can do balance credential, proof of ownership of NFT, or any data that is available on-chain. And now I will show you a demo of how it works with AdHardCard. So we have integration with a project by PEC, AnonAdHard. And big thanks to Yanis from AnonAdHAR who helped us build the first proof of concept and we are now iterating over it and improving to embed it into our solution. So what is happening now is that maybe some of you had interacted with AnonadHAR to get a cheaper ticket to DEF CON. So you would essentially scan a QR code from Adhar. And this QR code leads to a data that is stored on government website that is fetched to you. And then zero-knowledge circuit is running on your site and verifies that this data is correct and issues you credential. So this credential, it's on your device. Actual data is not leaving your device. It's there. And zero-knowledge proof is generated on your device, not on some server or issue or software. And, yeah, that's how it works. So you receive a credential. Initial generation takes a bit more time, but later you can use it very quickly and easily. And that's how you can create a query to this credential and use it for, for example, for voting. So in this example, I'm creating a request to prove that you're over 18 and that you're a unique person based on a non-ad hoc credential. I need to fill a few fields, including identifier of the issuer. And then we see wallet interface. So previously I was showing you mobile wallet interface and right now just because we have a multi-device experience if you have created your wallet with the same Ethereum address, then you can use it on mobile, but also in the web. So you are generating proof based on that credentials that you have received, and hola, you proved that you are over 18 and that you are a unique user based on your anonymous ADHAR credential. Thank you. Thank you very much for giving us a tour of digital identity. I'll get you to stand over here and we can go into the Q&A. So there were quite a few questions. So we can take a look at them here. So with selective disclosure, how do you prevent abuses from services asking you to share all your data, even if they don't need everything? So, yeah, like I think the example with the passport is a nice one. Why not just say, like, okay, so what's your passport number and your date of birth and your first name and your last name and the code, everything like this. So how do you prevent this? This is more a challenge of UI than actually technical. All the data is yours. So at the end, because you are holding the data, here is, I mean, you are going to give the data only if they ask to you. Here is more about the wallet. And so you hold data, and it's about the UI that ensures that, so that interprets the query that they are doing and tells very clear to the user exactly what information they are giving. Here, again, this is not easy it's a UI it's a UI UX challenge here of course a lot of social hacking can be but and that's something that's relatively new because I mean we are users we are not used to hold data in general. But this is something that here, UI, it's a lot of work in private ID with developing the wallet. We have been working really hard on this front. And I tell you that's not easy. But there are ways that a lot of things that can be improved. And there are ways to do this thing. Maybe you can warn the users. You're about to leak everything if you allow this. Cool. So another question. If we want to apply this at organization level, can we have shared verifiable credentials among multiple organization members? Right now, we do not support identities for organizations, but we are working on this. We have a few ideas how to implement this, and that would be in future releases, yes. Nice. But what's clear is that, I mean, and this is the thing, I mean, the identity is one, and then can be many organizations that can do claims on your same identity. And the other thing is, so this is the way to go. So it's like, and have like many claims working in your identity. Even you as an entity, you can do even claims, which is something that in the legacy world doesn't even need to happen. There is a lot of things. that in the legacy world doesn't need to happen. There is a lot of things. All the interactions that the humans are doing, say serious interactions, they can be converted to a claim. I mean, anything that you are doing. You are accessing to a web page, you can have a claim on that. Everything can be converted to a claim, and then you can prove. You can use that to prove something. You can put that in a database and do a query on this database, and you can prove something. You can put that in a database and do a query on this database and you can prove that, I don't know, you accessed 10 times this web page in the last month and you can do things like that. Yeah, have different tokens and things. I mean, they do this sometimes. So how does it work if I lose access to the keys? Can I export them? Yeah, basically you need to backup your keys, yes. But Basically, you need to backup your keys, yes. But what we are trying to solve right now is to be able to onboard Web2 users, we need something that is not key-based. We need a social login or this kind of login systems to work with your identity and we are working on enabling users to control their identity with regular existing web to login systems yes it's important to mention that so sorry means that you are holding your keys maybe you want to delegate this keeping to somebody else, but the first thing is that you should be able to choose. That's the first thing. So that would be the first condition. But even that here requires a lot of education. This is very much like holding the keys of your Ethereum wallet. I mean, you need to be responsible. So here there is a lot of usage uh learnings in their social recovery is the the other point which is also an interesting topic uh yeah but this is a way to go is in that direction yeah so i also saw some other yeah like ck email and things like this are doing like the account recovery and all sorts of interesting privacy preserving ish ways of doing maybe you don't do it for your millions of Bitcoin that you hold but for other accounts I think it can be good. We still have another minute or two so we can go through another question if you're happy to. How does it work? How does it compare to WorldID? Does it also use Semaphore? It's different. We are not using Semaphore, but it's also based on Merkle trees, just like Semaphore is a Merkle tree, essentially. But we are using it a bit differently. And yeah, I think the biggest difference is that compared to WorldID, we have many issues. We support all EVM chains natively. You just need to deploy a smart contract and you would be able to verify proofs. And we have all different kinds of credentials, not only your IRIS data that somehow is stored on their side and then you have a credential that, yeah. I think this is a super interesting point, especially for like the cypherpunk crowd who are the type of community, I think, who does like to reason between these different types of... Because I think it's quite an important point, actually, that there are multiple issuers. I mean, there are different ways to do things, and which is good for your application or another, and it's good. Sema4 is a good example of these legacy days where you need to use a specific cryptography to do identity. The cool thing now is that you can connect to Semaphore for example. I mean of course you need to implement it and maybe it's not worthy but you can connect to Semaphore the same way that you can connect to the government provider or a passport or email from someplace or or even I mean you can connect to different sources of attestations including semaphore I mean it's not an exception in order to have a claim in order to use this claim in order to build the proof you want to prove something you could prove that you have some account in semaphore and maybe a government ID and you can put that in the same circuit and And this is possible, thank you, to zero knowledge. And this is what is happening right now. I love it. Very cool. Well, that's all we've got time for. But, yeah, thank you for being the final talk in the Cypherpunk and Privacy session today. Thank you very much again. If you'd like to thank the speakers. Thank you.",
+ "eventId": "devcon-7",
+ "slot_start": 1731402000000,
+ "slot_end": 1731403800000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1tnxzF5on5Su2ji2vPSGG1B6RHmxzdqDiuloznxu_PIg",
+ "resources_slides": null,
+ "speakers": [
+ "jordi-baylina",
+ "oleksandr-brezhniev"
+ ]
+ },
+ "vector": [
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -279453,7 +278971,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -279462,7 +278979,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -279470,44 +278986,6 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "ensuring-data-availability-in-l2s",
- "sourceId": "SCUHA7",
- "title": "Ensuring Data Availability in L2s",
- "description": "The talk explores the risks associated with data availability (DA) providers in L2s, highlighting the necessary security guarantees of DA layers. It covers economic security considerations, security properties of DA attestations, and fraud detection mechanisms against data withholding attacks. The goal is to guide L2 users in understanding the different risk profiles of DA providers and assist developers and researchers in enhancing the security and functionality of L2 solutions.",
- "track": "Layer 2",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Research",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Risks"
- ],
- "tags": [
- "Layer 2s",
- "Data Availability",
- "Security",
- "risk",
- "Data Availability",
- "Layer 2s",
- "Security"
- ],
- "language": "en",
- "speakers": [
- "vincenzo-furcillo"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731654600000,
- "slot_end": 1731655200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1fP4Av0dDJM1g4BBb6EB2lsaWqOTPmZK7RkZvBv_vs-w"
- },
- "vector": [
0,
0,
0,
@@ -279515,7 +278993,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -279753,6 +279230,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -279808,7 +279287,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -280201,6 +279679,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -280212,6 +279691,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -280248,6 +279728,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -280260,7 +279741,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -280326,8 +279806,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -280425,6 +279903,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -280482,6 +279961,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -280562,7 +280042,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -280761,9 +280240,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -280776,6 +280257,45 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "enter-the-war-room-a-black-swan-simulation",
+ "sourceId": "HQSNWQ",
+ "title": "Enter the War Room: A Black Swan Simulation",
+ "description": "BREAKING: A key Layer 2 sequencer has suffered a complete outage for a brief period! As a consequence, many loans from the protocol DevaLend could not be paid, leading to liquidations and bad debt.\r\n\r\nIn this workshop, you will assume the role of one of the key players in this exciting simulation, and explore how to navigate through it. Propose how to navigate through the DevaLend situation and react as new scenarios evolve and respond to your ideas. Good Luck!",
+ "track": "Coordination",
+ "type": "Workshop",
+ "expertise": "Intermediate",
+ "audience": "Community",
+ "featured": false,
+ "doNotRecord": true,
+ "keywords": [
+ "Conflict"
+ ],
+ "tags": [
+ "Layer 2s",
+ "Governance",
+ "Emergency Plan",
+ "conflict",
+ "Emergency Plan",
+ "Governance",
+ "Layer 2s"
+ ],
+ "language": "en",
+ "speakers": [
+ "juan-carlos-bell-llinas",
+ "oxytocin"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731393000000,
+ "slot_end": 1731400200000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1QJBCSyIk_2YgSpZlJQsuZo3ymwCCG1XhQXN6zxlSBoQ"
+ },
+ "vector": [
0,
0,
0,
@@ -280787,6 +280307,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -280821,12 +280342,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -280838,62 +280357,11 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "ensuring-privacy-in-digital-identity-to-prevent-a-dystopian-crisis",
- "sourceId": "TZQYGY",
- "title": "Ensuring Privacy in Digital Identity to Prevent a Dystopian Crisis",
- "description": "This talk will explore introducing a method for privacy-preserving proof of user uniqueness in contexts like elections using DIDs, ZK, and VCs for verifying credentials without revealing unique identifiers while ensuring compatibility with multiple trust sources. This enables self-sovereign digital identity, allowing selective disclosure of verified credentials while protecting personal data, supporting privacy-preserving KYC, sybil resistance, compliant access to financial services, and more.",
- "track": "Cypherpunk & Privacy",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "tags": [
- "Identity",
- "Zero-Knowledge",
- "Security",
- "zk",
- "proof",
- "Identity",
- "Security",
- "Zero-Knowledge"
- ],
- "keywords": [
- "Zk",
- "Proof"
- ],
- "duration": 1426,
- "language": "en",
- "sources_swarmHash": "27893580368e8396780c9f103b3d94703c4ab1700db60ed5816b3334de7aff27",
- "sources_youtubeId": "6EJBsHydyVU",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733207e3a168eb53546fce2.vtt",
- "transcript_text": " Hello everybody, I'm Jordi Bailina, I'm Sasha from PrivatID. What's digital identity? To make it easy, digital identity is when you sign into a page, actually you're using your digital identity currently digital identity is Controlled by very few corporations your Facebook Twitter and so on just a side note Here in the web 3 means not even governed by governments I mean governments here could be a good allies to implement self-sovereign identity because probably governments they don't want to give the identity to these big corporations so it's very far it's fragmented I mean it's not very fragmented but I mean there is four five four five six seven big corporations that holds most of the people's identity and this from in addition and other things this gives us a really bad UX. I mean, I'm sure that maybe not here, but a lot of users have problems with passwords, and managing passwords, managing connections, emails, and all this kind of digital identity. So when we go to Web 3 and we are building dApps, actually we need identity too. I mean, we have the two exceptions. I mean, when you are transferring funds, maybe you don't need an identity. You just, well, you have some sort of identity, which is an account, but you don't really need identity. But if you want to do any other application, I don't know, voting, or you want to do, connect to a DAO or something. You will need some sort of login. You need some sort of identity. So we need identity in the Web3. And when we go to identity in the Web3, we may end up doing very much the same. If this is controlled by very few corporations, then what is happening is that it's even more fragmented and the UX is even worse. And not only that I mean the digit when we go to the center lights there are other risks and other important things that are happening of course we have the the privacy thing if we are publishing data this latter can be leakage easily and there are a lot of challenge that we need to solve on that. So how this solution needs to be? Of course, it needs to be self-sovereign. I mean, it needs to be decentralized. Each one needs to hold their own identity. And you are kind of a server of your identity. I mean, you are the identity. The protocol privacy needs to be by default and by design and by design in privacy needs to be here is where zero knowledge is important I mean the centralized identity without zero knowledge is impossible to make here I want to do an a note and is that the zero knowledge technology has been evolved a lot if you in the last in the last years if you, if you just go back three years ago, it was difficult to build identity systems because you end up using your own cryptography, you end up using, I mean, you had to do identity in a specific way so that you can apply zero knowledge. Currently, the zero knowledge technology, and thank you to all these layer tools and all this evolution that happens in the last year, it's much more powerful, much more faster, and it's perfectly possible to use normal cryptography. That means that you can use current attestations, I mean, the signatures of the governments, the signatures of the organizations that are already happening so a lot of attestations real attestations that are actually happening you can use them in zero knowledge you can build these decentralized database of that is attestation it's a single database where everybody just share such as just have access to a small part of that and then you can single source of truth and then you can prove things around that and finally of course this needs to be a open standard simple standard it will not come for big corporations it will come from the roots it will come from the like TCP IP I mean this needs to be something that should be simple so as an example of hope to connect this identity to these signatures, to these attestations that already happen in the world, I'm going to give the word to Sasha that will explain the work that we are doing in Privado ID. Sasha. Thank you. Thank you, Jordi. So, yeah, what's Privado ID? Privado ID is a self-sovereign identity solution, but also it's a middleware. It's an infrastructure so that you are able to build your own applications that have identity, that can work on different chains, multiple devices. And it's based on industry standards. It's based on W3C, DADs, and verifiable credentials. So it's an interoperable system that you're able to use and build on top of it. And also it's powered by zero knowledge proofs. So whenever you are using it, you're not sharing your actual data. You're sharing only proof that you're eligible to do something, like you're over 18 to purchase liquor in the store, yeah? Without providing whole document, without sharing your picture, without sharing your actual date of birth, your passport number, and so on. And key features that we have is that we are unifying this fragmented identity. We are bringing all different chains together, we are making it work on different multiple devices at the same time. And also, we are unifying Web2 and Web3 systems. So it's usable on the apps and on your regular applications and also on regular stores where you would go and buy things off-chain, offline. of chain offline and very important that for many things you need to do it only once like if you go and ask you I see you would do it only once then your credentials your data would be stored on your device under your control, and you would be sharing some pieces of it on request. You would be sharing just proofs, for example, that you're over 18, as I said, or maybe for some cases you would be selectively disclosing some data. Maybe it would be, for example, seat number in your ticket credential, let's say. Yeah, something like that. And we have two other very important features and very useful. One is privacy-preserving proof of uniqueness. And another, decentralized trustless issuance, where a smart contract is issuing you credentials. So that's why it could be trustless in terms that you are not trusting any specific centralized authority to issue you credential. You can do it on-chain in a decentralized manner, but also it could be done in privacy-preserving manner. So how is this proof of uniqueness working that we have? It's based on credentials. It could be different kinds of credentials. It could be biometrical data, yeah? But also it could be like phone number or credential that you have from your employer, that you are employee. And then you can use it to do, for example, voting in a company anonymous survey without disclosing who you are and without doing your iris scan to prove that you're unique, employer already knows that you're unique. It can control this data and issue credential. And then you are able to use it to prove uniqueness without disclosing who you actually are. And do specific action only once, like voting. And it's not only limited by credential, so you can use it on a specific credential for a specific use case, but also we have a special way to distinguish between different sessions even inside one application for example if you are doing multiple votings um or multiple surveys give a different context for the user and nullifier, your unique identifier for this purpose would be different between each session so that you would be anonymous, it would not not be possible to track who is actually voting between these different sessions. And as I said, there is different use cases. You can use it even for nationwide voting. For example, it could be based on a biometrical document like AdHardCard, and then you would prove that you're unique and you're eligible to vote and count this vote only once. And decentralized trustless issuance is a feature that allows you to do this in a privacy-preserving manner so that even there is no centralized issuer that knows who you are, so that issuer would be able to track who is acting and possibly de-anonymize you. So now I will show you how it works. And first demo is just a simple, very, very simple application where you are able to prove that your ownership of Ethereum address. So you would receive a credential that you are owner of Ethereum address. So what you need to do is actually you're just authenticating to the system, and then you send a transaction, and that's it. Credential is issued. Data was already on chain, so nothing needs to be additionally proven. So, it's very simple. And voila, you have a credential. In the same way, we can do balance credential, proof of ownership of NFT, or any data that is available on-chain. And now I will show you a demo of how it works with AdHardCard. So we have integration with a project by PEC, AnonAdHard. And big thanks to Yanis from AnonAdHAR who helped us build the first proof of concept and we are now iterating over it and improving to embed it into our solution. So what is happening now is that maybe some of you had interacted with AnonadHAR to get a cheaper ticket to DEF CON. So you would essentially scan a QR code from Adhar. And this QR code leads to a data that is stored on government website that is fetched to you. And then zero-knowledge circuit is running on your site and verifies that this data is correct and issues you credential. So this credential, it's on your device. Actual data is not leaving your device. It's there. And zero-knowledge proof is generated on your device, not on some server or issue or software. And, yeah, that's how it works. So you receive a credential. Initial generation takes a bit more time, but later you can use it very quickly and easily. And that's how you can create a query to this credential and use it for, for example, for voting. So in this example, I'm creating a request to prove that you're over 18 and that you're a unique person based on a non-ad hoc credential. I need to fill a few fields, including identifier of the issuer. And then we see wallet interface. So previously I was showing you mobile wallet interface and right now just because we have a multi-device experience if you have created your wallet with the same Ethereum address, then you can use it on mobile, but also in the web. So you are generating proof based on that credentials that you have received, and hola, you proved that you are over 18 and that you are a unique user based on your anonymous ADHAR credential. Thank you. Thank you very much for giving us a tour of digital identity. I'll get you to stand over here and we can go into the Q&A. So there were quite a few questions. So we can take a look at them here. So with selective disclosure, how do you prevent abuses from services asking you to share all your data, even if they don't need everything? So, yeah, like I think the example with the passport is a nice one. Why not just say, like, okay, so what's your passport number and your date of birth and your first name and your last name and the code, everything like this. So how do you prevent this? This is more a challenge of UI than actually technical. All the data is yours. So at the end, because you are holding the data, here is, I mean, you are going to give the data only if they ask to you. Here is more about the wallet. And so you hold data, and it's about the UI that ensures that, so that interprets the query that they are doing and tells very clear to the user exactly what information they are giving. Here, again, this is not easy it's a UI it's a UI UX challenge here of course a lot of social hacking can be but and that's something that's relatively new because I mean we are users we are not used to hold data in general. But this is something that here, UI, it's a lot of work in private ID with developing the wallet. We have been working really hard on this front. And I tell you that's not easy. But there are ways that a lot of things that can be improved. And there are ways to do this thing. Maybe you can warn the users. You're about to leak everything if you allow this. Cool. So another question. If we want to apply this at organization level, can we have shared verifiable credentials among multiple organization members? Right now, we do not support identities for organizations, but we are working on this. We have a few ideas how to implement this, and that would be in future releases, yes. Nice. But what's clear is that, I mean, and this is the thing, I mean, the identity is one, and then can be many organizations that can do claims on your same identity. And the other thing is, so this is the way to go. So it's like, and have like many claims working in your identity. Even you as an entity, you can do even claims, which is something that in the legacy world doesn't even need to happen. There is a lot of things. that in the legacy world doesn't need to happen. There is a lot of things. All the interactions that the humans are doing, say serious interactions, they can be converted to a claim. I mean, anything that you are doing. You are accessing to a web page, you can have a claim on that. Everything can be converted to a claim, and then you can prove. You can use that to prove something. You can put that in a database and do a query on this database, and you can prove something. You can put that in a database and do a query on this database and you can prove that, I don't know, you accessed 10 times this web page in the last month and you can do things like that. Yeah, have different tokens and things. I mean, they do this sometimes. So how does it work if I lose access to the keys? Can I export them? Yeah, basically you need to backup your keys, yes. But Basically, you need to backup your keys, yes. But what we are trying to solve right now is to be able to onboard Web2 users, we need something that is not key-based. We need a social login or this kind of login systems to work with your identity and we are working on enabling users to control their identity with regular existing web to login systems yes it's important to mention that so sorry means that you are holding your keys maybe you want to delegate this keeping to somebody else, but the first thing is that you should be able to choose. That's the first thing. So that would be the first condition. But even that here requires a lot of education. This is very much like holding the keys of your Ethereum wallet. I mean, you need to be responsible. So here there is a lot of usage uh learnings in their social recovery is the the other point which is also an interesting topic uh yeah but this is a way to go is in that direction yeah so i also saw some other yeah like ck email and things like this are doing like the account recovery and all sorts of interesting privacy preserving ish ways of doing maybe you don't do it for your millions of Bitcoin that you hold but for other accounts I think it can be good. We still have another minute or two so we can go through another question if you're happy to. How does it work? How does it compare to WorldID? Does it also use Semaphore? It's different. We are not using Semaphore, but it's also based on Merkle trees, just like Semaphore is a Merkle tree, essentially. But we are using it a bit differently. And yeah, I think the biggest difference is that compared to WorldID, we have many issues. We support all EVM chains natively. You just need to deploy a smart contract and you would be able to verify proofs. And we have all different kinds of credentials, not only your IRIS data that somehow is stored on their side and then you have a credential that, yeah. I think this is a super interesting point, especially for like the cypherpunk crowd who are the type of community, I think, who does like to reason between these different types of... Because I think it's quite an important point, actually, that there are multiple issuers. I mean, there are different ways to do things, and which is good for your application or another, and it's good. Sema4 is a good example of these legacy days where you need to use a specific cryptography to do identity. The cool thing now is that you can connect to Semaphore for example. I mean of course you need to implement it and maybe it's not worthy but you can connect to Semaphore the same way that you can connect to the government provider or a passport or email from someplace or or even I mean you can connect to different sources of attestations including semaphore I mean it's not an exception in order to have a claim in order to use this claim in order to build the proof you want to prove something you could prove that you have some account in semaphore and maybe a government ID and you can put that in the same circuit and And this is possible, thank you, to zero knowledge. And this is what is happening right now. I love it. Very cool. Well, that's all we've got time for. But, yeah, thank you for being the final talk in the Cypherpunk and Privacy session today. Thank you very much again. If you'd like to thank the speakers. Thank you.",
- "eventId": "devcon-7",
- "slot_start": 1731402000000,
- "slot_end": 1731403800000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1tnxzF5on5Su2ji2vPSGG1B6RHmxzdqDiuloznxu_PIg",
- "resources_slides": null,
- "speakers": [
- "jordi-baylina",
- "oleksandr-brezhniev"
- ]
- },
- "vector": [
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -281130,6 +280598,9 @@
0,
0,
0,
+ 6,
+ 6,
+ 0,
0,
0,
0,
@@ -281189,8 +280660,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -281640,9 +281109,9 @@
0,
0,
0,
- 6,
0,
0,
+ 2,
0,
0,
0,
@@ -281652,7 +281121,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -281673,6 +281141,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -281689,7 +281158,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -281781,6 +281249,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -281864,7 +281333,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -281879,6 +281347,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -281923,7 +281392,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -282138,17 +281606,56 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "epf-day-introduction",
+ "sourceId": "PE8JHU",
+ "title": "EPF Day Introduction",
+ "description": "Josh and Mario introduce the fifth cohort's EPF Day.",
+ "track": "[CLS] EPF Day",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [],
+ "tags": [
+ "EPF",
+ "Ethereum Roadmap",
+ "Layer 1"
+ ],
+ "language": "en",
+ "speakers": [
+ "mario-havel",
+ "josh-davis"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731467700000,
+ "slot_end": 1731468600000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1UgPaeQAkzm7-SuT2jdxRMLHcVJEzy3CxxHN_BL0ftCg"
+ },
+ "vector": [
0,
0,
0,
@@ -282164,6 +281671,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -282201,11 +281709,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -282218,45 +281724,6 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "enter-the-war-room-a-black-swan-simulation",
- "sourceId": "HQSNWQ",
- "title": "Enter the War Room: A Black Swan Simulation",
- "description": "BREAKING: A key Layer 2 sequencer has suffered a complete outage for a brief period! As a consequence, many loans from the protocol DevaLend could not be paid, leading to liquidations and bad debt.\r\n\r\nIn this workshop, you will assume the role of one of the key players in this exciting simulation, and explore how to navigate through it. Propose how to navigate through the DevaLend situation and react as new scenarios evolve and respond to your ideas. Good Luck!",
- "track": "Coordination",
- "type": "Workshop",
- "expertise": "Intermediate",
- "audience": "Community",
- "featured": false,
- "doNotRecord": true,
- "keywords": [
- "Conflict"
- ],
- "tags": [
- "Layer 2s",
- "Governance",
- "Emergency Plan",
- "conflict",
- "Emergency Plan",
- "Governance",
- "Layer 2s"
- ],
- "language": "en",
- "speakers": [
- "juan-carlos-bell-llinas",
- "oxytocin"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731393000000,
- "slot_end": 1731400200000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1QJBCSyIk_2YgSpZlJQsuZo3ymwCCG1XhQXN6zxlSBoQ"
- },
- "vector": [
0,
0,
0,
@@ -282268,7 +281735,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -282494,6 +281960,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -282560,8 +282028,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -282954,6 +282420,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -283075,7 +282542,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -283105,7 +282571,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -283132,6 +282597,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -283213,7 +282679,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -283243,6 +282708,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -283312,7 +282778,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -283503,12 +282968,14 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -283516,6 +282983,46 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "epf-day-panel",
+ "sourceId": "ZMRJ9B",
+ "title": "EPF Day Panel",
+ "description": "Panel with former fellows who became core devs and mentors",
+ "track": "[CLS] EPF Day",
+ "type": "Panel",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "tags": [],
+ "keywords": [],
+ "duration": 2235,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "sOhT-LfOTkw",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": "67347fbe9dbb7a90e1b8c58d",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67347fbe9dbb7a90e1b8c58d.vtt",
+ "transcript_text": " Okay, I guess we can start. We're already a bit late, but we've managed finally to get all the panelists here. So, yeah, first of all, thank you so much for being here, all the fellows on the panel and all the fellows and attendees and mentors who managed to make it to the end of the EPF day of 2024. And we are wrapping up today's EPF day with a special panel discussion. And I call it the E panel discussion because it's, you know, Ethereum, but it's also Echo, Ethan and Anyco. Completely randomly chosen fellows, of course, to join us. I chose you guys, I invited you guys, because all of you have been in previous cohorts of the fellowship, and today you became full-time contributors, you became working with client teams. I will start with a quick intro, and I will do your intro. You can add if you want something because I want to move to the questions. But so we have here three people who have I believe are representing all kinds of possibilities that EPF can give you because we talk a lot about client teams and the core contributors and so on, but not everybody from EPF is going to end up working in a client team. And there are other kinds of futures for you. And I will start with the lady here, Eniko, who's been working on debt packaging as a part of creating a verifiable deterministic builds for Ethereum clients and has been working on it for more than a year now as a grantee. So continues her EPF work on a grant and working on something which is, you know, Ethereum tooling but not directly to the clients. So a great example of like how how people from EPF can work outside of clients. We have Ethan, who is on the other side, directly in the client, working full-time in Lighthouse as a core developer. And we have Echo, who is a researcher in ARG, or Applied Research Group in Ethereum Foundation. So we have all the representatives of a research flow. So yeah, all kinds of backgrounds. And I don't want to actually talk really about your EPF experience itself, because you can actually find it. If you go to cohort three, cohort four repository, all of the experience, all of the work done by these people is there, it's open.",
+ "eventId": "devcon-7",
+ "slot_start": 1731489300000,
+ "slot_end": 1731492000000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1zfYthY0BXd-oH251a-aAijUCaZpAylXrBQ0_5terdHk",
+ "resources_slides": null,
+ "speakers": [
+ "echo",
+ "eitan",
+ "eniko-nagy",
+ "mario-havel"
+ ]
+ },
+ "vector": [
0,
0,
0,
@@ -283531,6 +283038,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -283570,7 +283078,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -283579,7 +283086,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -283587,39 +283093,6 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "epf-day-introduction",
- "sourceId": "PE8JHU",
- "title": "EPF Day Introduction",
- "description": "Josh and Mario introduce the fifth cohort's EPF Day.",
- "track": "[CLS] EPF Day",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Community",
- "featured": false,
- "doNotRecord": false,
- "keywords": [],
- "tags": [
- "EPF",
- "Ethereum Roadmap",
- "Layer 1"
- ],
- "language": "en",
- "speakers": [
- "mario-havel",
- "josh-davis"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731467700000,
- "slot_end": 1731468600000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1UgPaeQAkzm7-SuT2jdxRMLHcVJEzy3CxxHN_BL0ftCg"
- },
- "vector": [
0,
0,
0,
@@ -283635,7 +283108,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -283855,7 +283327,11 @@
0,
0,
0,
+ 6,
0,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -283925,8 +283401,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -284387,7 +283861,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -284564,7 +284037,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -284676,7 +284148,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -284862,9 +284333,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -284877,6 +284350,49 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "epf-nethermindil-evm",
+ "sourceId": "QJNNDL",
+ "title": "EPF - Nethermind/IL-EVM",
+ "description": "This talk will discuss my EPF work on Nethermind's IL-EVM project, which included developing tools to analyze EVM execution patterns, writing (optimised) opcode and top pattern implementations, and conducting and writing tests.",
+ "track": "[CLS] EPF Day",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "tags": [
+ "Core",
+ "Protocol"
+ ],
+ "keywords": [
+ "EVM",
+ "Optimization"
+ ],
+ "duration": 699,
+ "language": "en",
+ "sources_swarmHash": "ee30c44852dd78c6f9f71de6a552443c01b1cd6fa673737ad972191ff03e328d",
+ "sources_youtubeId": "3oQdLXm4PiM",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673428639dbb7a90e1a39ee7.vtt",
+ "transcript_text": " . This is my project. This is an of the loose timeline of the project. So week 6 and 8 were sort of done on some warm up tasks to kind of get a feel of the code base. Week 9 and 12 was spent on doing some research for the upcoming task, which was basically gathering N-gram stats. The core focus of the project was doing the stat analyzer implementation, which happened between week 13 and 16. And then week 17 and 18, I was basically running the stat analyzer, getting the N-grams, and then actually doing the N-gram implementations for pattern detection mode for the ILEVM. And week 19 plus, I was just basically doing bug fixing and also just generally looking at ILEvm and bugs and i found like five opcodes that had problems and i fixed those um so right so the first part was basically it was it was my first task i just joined i leave i just started the project and uh i think it was the first meeting with the mentor and I basically was, the mentor asked me do you know where I was because the mentor was sort of focusing on EOF implementation so nobody was working on IL-EVM. I just sort of took the task that was sort of remaining and I started working on it and then my mentor joined in and that was sort of finished. The next task that I did was some core DB stats. Again, this is a warm-up task. Where I just tried to get some Ngram stats from the database. So these are not execution stats. The implementation was very slow. It was done over the weekend. Again, it was a warm-up task. So now we kind of come to the, you know, the... Oh, this is the research and algorithm. So there was a lot of research and literature review that was done for basically big data analysis because we are dealing with execution stats for Ngram, which is actually a lot of data. And these were some of the papers that were run, that I read. Of note are basically the heavy keepers and also sliding sketches in time zones for data stream processing because these are both single pass algorithms. Because we wanted to implement an algorithm that is single pass for this amount of data and is efficient. So after a while, we just sort of, with some discussions with the mentors, we just settled on simple count and sketch. The basic principle of the count and sketch is that you have sort of D hash functions, and then you have like, let's say, W buckets. And whenever an item comes, that gets hashed, and it's put into one of these buckets. So for example, here you can see just data for one item. So in this case, the true count will be the lowest count. That is one. 25 would be an overestimation. That means there's a collision. But because we have many hash functions, if you take just the minimum of the count, you can actually get the true count adjusted with errors, et cetera, for the data that we need. So, additionally, you have these bounds of epsilon and delta that control the probability and the error that the data structure has. And you can actually configure the stats analyzer to use both width, depth, epsilon, and delta. So now for the main thing, which is building the stat analyzer. OK, the first part was encoding the n-grams. So to encode the task was given is that basically we just need to find two to seven opcode patterns, like two to seven, the size of the engram is two to seven, and the way to basically do it, and this could work for like up to n engrams actually, it's only limited by the data type. But basically as the engrams are coming, as the opcodes are coming in, we just basically left shift opcode and then we or it with the next opcode and we encode it into a long value. Because a long value has 8 bytes, so it can actually encode 8 opcodes. And if you have used one of the data types that is common in clients is you have a 32 byte data type like UN256. So technically it could go up to like you have a 32 byte data type like UN256. So technically it could go up to like, I don't know, 32, 32, 32 Ngram like size of the pattern can actually technically go up to. Oh, wait. Right, then comes tracking the Ngrams. So instead of like tracking n-gram separately, like of 2, 3, 4, 5, 6, 7, what we can do is we just get the n-gram, the long value that we have. We find the n-gram that is the maximum of the size. Like, for example, if we had the size 3, right? And you can actually have 0xFFFF, which is size 2. That's the maximum because you cannot have anything over this would be a size 3. And then we can actually select that out. And basically, if you have like an n-gram like pop, pop, add data, you can actually just iterate over those that long value and actually get these three n-grams that don't have to be tracked individually and saved anywhere and they just basically you have these sort of ephemeral long values that just simply go into the cm sketch for accumulation. Yeah, iterates on the basis of the core of the SAT analyzers, it's a real piece of the count-win sketches. And you have a top-k queue. You iterate over the bytecode, you encode the N-gram, you accumulate the counts in the CM sketch. Also, a new sketch is provisioned based on what our error threshold is, like what is the max error we're able to tolerate. So we can configure that and then new sketches are provisioned based on that. It provides the top K patterns and provides the error and confidence for the stats. So you can actually have varied performances for this, so you can actually make it really fast and less accurate or slower and more accurate. You have that capability. Right, so then how do we gather the data? The data is done as a trace. It's a trace plug-in. It's straight from the EVM. You can configure this to be enabled or disabled. The tracer then finally dumps the data. It calls Stats Analyzer and then it can dump the data into a file as a trace on the file. So how does that look? This is sort of the output. You can see initial block number, current block number, error per item, confidence, and these are the stats, for example. You have the pattern, you have the bytes that it is, and then you have the count that you've observed. You can go and you can specify how many you want. To give an idea of the configuration, that you can see all these are, like this is the config that you can do. You have enabled the file to write to the right frequencies, like how many blocks you want to write this to. Ignore set, like you want to ignore jump destination. That's not really useful for analysis, so you can actually write ignore set. You have an instruction queue size, the size of the queue used to gather instructions per block, right? Because that, again, it can increase as time goes, so you want that to be configurable. You have the processing queue size, how many blocks are now stored for processing. You have the number of buckets that you can put in the sketch. You have the number of hash functions that you can put in the sketch. You can put the max error that you're willing to tolerate in the CM sketch. You have the sketch minimum confidence that you want to tolerate you can analyze the top n grams to track like ten ten thousand hundred thousand you can put analyze them in support threshold this is this is sort of like a filter both of these analyzer capacity and threshold. Then you have the sketch buffer size, and you have the sketch reset and reuse threshold, which is where it gets provisioned a new sketch based on error. So that's the plugin config. The next section was pattern discovery, selection, and implementation. So, right. so, wait, right, so I used the stat analyzer. I did two sets, one was top 10 patterns of two size two, and that got merged. Then I did 11 patterns of five to eight opcodes that's still under review, but these are basically the pattern matching mode of IL-EVM. So the opcode implementation has to be in parity with the EVM implementation, but you have certain opportunities of optimizing because you have a few patterns together. But the major optimization will come in the IL implementation because we have two implementations to do. One is the pattern matching and the IL implementation. The last was testing, that was just started like a week back, so it's still like very much a work in progress. So this involved testing IL, testing the pattern implementations, also the IL implementations. And the way we were doing this was basically we have two chains, and we have an enhanced chain where we enable the IL-EVM and a normal chain where we don't, and then we compare the state route. But doing that also there are caveats because what if there's an out of gas error? Well, both those chains would be the same. What if there's a, you know, spec is not enabled. Again, you will not, you'll get the state route passing the comparison. Invalid jump destination. So all these situations were there where it would just pass the test, but it's like the implementation is incorrect. So it's quite hard to test this. So anyway, so there was some detection that happened over the weekend. I think five opcodes that I fixed while testing, and testing for the analyzer opcodes and patterns are still work in progress. And well, thanks to all these I mean, my main mentors were Shimon and Ayman. And a big thank you to Lukash, Ben Adams, Damien for being sort of weekly there in the ILVM calls. And Marik and Tomas for actually enabling at the beginning to help me meet all my mentors and setting the meetings up. So, yeah. Thanks. Thank you so much. Lovely. Thank you.",
+ "eventId": "devcon-7",
+ "slot_start": 1731470400000,
+ "slot_end": 1731471300000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/13ze8Pr4OxtxoFIIxGDV0SAGLb_aIJtknEOqxz5Ct5lA",
+ "resources_slides": null,
+ "speakers": [
+ "siddharth-vaderaa"
+ ]
+ },
+ "vector": [
0,
0,
0,
@@ -284892,6 +284408,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -284935,14 +284452,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -284950,37 +284465,6 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "epf-day-panel",
- "sourceId": "ZMRJ9B",
- "title": "EPF Day Panel",
- "description": "Panel with former fellows who became core devs and mentors",
- "track": "[CLS] EPF Day",
- "type": "Panel",
- "expertise": "Intermediate",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "keywords": [],
- "tags": [],
- "language": "en",
- "speakers": [
- "mario-havel",
- "eniko-nagy",
- "echo",
- "eitan"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731489300000,
- "slot_end": 1731492000000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1zfYthY0BXd-oH251a-aAijUCaZpAylXrBQ0_5terdHk"
- },
- "vector": [
0,
0,
0,
@@ -284996,7 +284480,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -285219,6 +284702,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -285286,11 +284770,7 @@
0,
0,
0,
- 6,
0,
- 6,
- 6,
- 6,
0,
0,
0,
@@ -285966,6 +285446,10 @@
0,
0,
0,
+ 2,
+ 2,
+ 0,
+ 0,
0,
0,
0,
@@ -286219,9 +285703,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -286234,6 +285720,39 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "erc-3668-on-linea-built-in-trust-minimized-l2-to-l1-data-retrieval",
+ "sourceId": "FARJAG",
+ "title": "ERC-3668 on Linea: built-in, trust-minimized L2 to L1 data retrieval",
+ "description": "ERC-3668 (aka. CCIP-read) enable L1 contracts to access Linea state. No special library need to be integrated, everything is built into the protocol and secured by Linea's zero-knowledge proofs. During this presentation, we will go into the details of how this works, the benefits and use cases you can start building today.",
+ "track": "Layer 2",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "Cross-chain"
+ ],
+ "tags": [
+ "Layer 2s",
+ "Zero-Knowledge"
+ ],
+ "language": "en",
+ "speakers": [
+ "julien"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731475800000,
+ "slot_end": 1731477600000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1caoeThC6_UrDRFE2PQIcbIczFePi9G_E72Ud7YuJejc"
+ },
+ "vector": [
0,
0,
0,
@@ -286241,6 +285760,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -286294,11 +285814,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -286311,49 +285829,6 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "epf-nethermindil-evm",
- "sourceId": "QJNNDL",
- "title": "EPF - Nethermind/IL-EVM",
- "description": "This talk will discuss my EPF work on Nethermind's IL-EVM project, which included developing tools to analyze EVM execution patterns, writing (optimised) opcode and top pattern implementations, and conducting and writing tests.",
- "track": "[CLS] EPF Day",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "tags": [
- "Core",
- "Protocol"
- ],
- "keywords": [
- "EVM",
- "Optimization"
- ],
- "duration": 699,
- "language": "en",
- "sources_swarmHash": "ee30c44852dd78c6f9f71de6a552443c01b1cd6fa673737ad972191ff03e328d",
- "sources_youtubeId": "3oQdLXm4PiM",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673428639dbb7a90e1a39ee7.vtt",
- "transcript_text": " . This is my project. This is an of the loose timeline of the project. So week 6 and 8 were sort of done on some warm up tasks to kind of get a feel of the code base. Week 9 and 12 was spent on doing some research for the upcoming task, which was basically gathering N-gram stats. The core focus of the project was doing the stat analyzer implementation, which happened between week 13 and 16. And then week 17 and 18, I was basically running the stat analyzer, getting the N-grams, and then actually doing the N-gram implementations for pattern detection mode for the ILEVM. And week 19 plus, I was just basically doing bug fixing and also just generally looking at ILEvm and bugs and i found like five opcodes that had problems and i fixed those um so right so the first part was basically it was it was my first task i just joined i leave i just started the project and uh i think it was the first meeting with the mentor and I basically was, the mentor asked me do you know where I was because the mentor was sort of focusing on EOF implementation so nobody was working on IL-EVM. I just sort of took the task that was sort of remaining and I started working on it and then my mentor joined in and that was sort of finished. The next task that I did was some core DB stats. Again, this is a warm-up task. Where I just tried to get some Ngram stats from the database. So these are not execution stats. The implementation was very slow. It was done over the weekend. Again, it was a warm-up task. So now we kind of come to the, you know, the... Oh, this is the research and algorithm. So there was a lot of research and literature review that was done for basically big data analysis because we are dealing with execution stats for Ngram, which is actually a lot of data. And these were some of the papers that were run, that I read. Of note are basically the heavy keepers and also sliding sketches in time zones for data stream processing because these are both single pass algorithms. Because we wanted to implement an algorithm that is single pass for this amount of data and is efficient. So after a while, we just sort of, with some discussions with the mentors, we just settled on simple count and sketch. The basic principle of the count and sketch is that you have sort of D hash functions, and then you have like, let's say, W buckets. And whenever an item comes, that gets hashed, and it's put into one of these buckets. So for example, here you can see just data for one item. So in this case, the true count will be the lowest count. That is one. 25 would be an overestimation. That means there's a collision. But because we have many hash functions, if you take just the minimum of the count, you can actually get the true count adjusted with errors, et cetera, for the data that we need. So, additionally, you have these bounds of epsilon and delta that control the probability and the error that the data structure has. And you can actually configure the stats analyzer to use both width, depth, epsilon, and delta. So now for the main thing, which is building the stat analyzer. OK, the first part was encoding the n-grams. So to encode the task was given is that basically we just need to find two to seven opcode patterns, like two to seven, the size of the engram is two to seven, and the way to basically do it, and this could work for like up to n engrams actually, it's only limited by the data type. But basically as the engrams are coming, as the opcodes are coming in, we just basically left shift opcode and then we or it with the next opcode and we encode it into a long value. Because a long value has 8 bytes, so it can actually encode 8 opcodes. And if you have used one of the data types that is common in clients is you have a 32 byte data type like UN256. So technically it could go up to like you have a 32 byte data type like UN256. So technically it could go up to like, I don't know, 32, 32, 32 Ngram like size of the pattern can actually technically go up to. Oh, wait. Right, then comes tracking the Ngrams. So instead of like tracking n-gram separately, like of 2, 3, 4, 5, 6, 7, what we can do is we just get the n-gram, the long value that we have. We find the n-gram that is the maximum of the size. Like, for example, if we had the size 3, right? And you can actually have 0xFFFF, which is size 2. That's the maximum because you cannot have anything over this would be a size 3. And then we can actually select that out. And basically, if you have like an n-gram like pop, pop, add data, you can actually just iterate over those that long value and actually get these three n-grams that don't have to be tracked individually and saved anywhere and they just basically you have these sort of ephemeral long values that just simply go into the cm sketch for accumulation. Yeah, iterates on the basis of the core of the SAT analyzers, it's a real piece of the count-win sketches. And you have a top-k queue. You iterate over the bytecode, you encode the N-gram, you accumulate the counts in the CM sketch. Also, a new sketch is provisioned based on what our error threshold is, like what is the max error we're able to tolerate. So we can configure that and then new sketches are provisioned based on that. It provides the top K patterns and provides the error and confidence for the stats. So you can actually have varied performances for this, so you can actually make it really fast and less accurate or slower and more accurate. You have that capability. Right, so then how do we gather the data? The data is done as a trace. It's a trace plug-in. It's straight from the EVM. You can configure this to be enabled or disabled. The tracer then finally dumps the data. It calls Stats Analyzer and then it can dump the data into a file as a trace on the file. So how does that look? This is sort of the output. You can see initial block number, current block number, error per item, confidence, and these are the stats, for example. You have the pattern, you have the bytes that it is, and then you have the count that you've observed. You can go and you can specify how many you want. To give an idea of the configuration, that you can see all these are, like this is the config that you can do. You have enabled the file to write to the right frequencies, like how many blocks you want to write this to. Ignore set, like you want to ignore jump destination. That's not really useful for analysis, so you can actually write ignore set. You have an instruction queue size, the size of the queue used to gather instructions per block, right? Because that, again, it can increase as time goes, so you want that to be configurable. You have the processing queue size, how many blocks are now stored for processing. You have the number of buckets that you can put in the sketch. You have the number of hash functions that you can put in the sketch. You can put the max error that you're willing to tolerate in the CM sketch. You have the sketch minimum confidence that you want to tolerate you can analyze the top n grams to track like ten ten thousand hundred thousand you can put analyze them in support threshold this is this is sort of like a filter both of these analyzer capacity and threshold. Then you have the sketch buffer size, and you have the sketch reset and reuse threshold, which is where it gets provisioned a new sketch based on error. So that's the plugin config. The next section was pattern discovery, selection, and implementation. So, right. so, wait, right, so I used the stat analyzer. I did two sets, one was top 10 patterns of two size two, and that got merged. Then I did 11 patterns of five to eight opcodes that's still under review, but these are basically the pattern matching mode of IL-EVM. So the opcode implementation has to be in parity with the EVM implementation, but you have certain opportunities of optimizing because you have a few patterns together. But the major optimization will come in the IL implementation because we have two implementations to do. One is the pattern matching and the IL implementation. The last was testing, that was just started like a week back, so it's still like very much a work in progress. So this involved testing IL, testing the pattern implementations, also the IL implementations. And the way we were doing this was basically we have two chains, and we have an enhanced chain where we enable the IL-EVM and a normal chain where we don't, and then we compare the state route. But doing that also there are caveats because what if there's an out of gas error? Well, both those chains would be the same. What if there's a, you know, spec is not enabled. Again, you will not, you'll get the state route passing the comparison. Invalid jump destination. So all these situations were there where it would just pass the test, but it's like the implementation is incorrect. So it's quite hard to test this. So anyway, so there was some detection that happened over the weekend. I think five opcodes that I fixed while testing, and testing for the analyzer opcodes and patterns are still work in progress. And well, thanks to all these I mean, my main mentors were Shimon and Ayman. And a big thank you to Lukash, Ben Adams, Damien for being sort of weekly there in the ILVM calls. And Marik and Tomas for actually enabling at the beginning to help me meet all my mentors and setting the meetings up. So, yeah. Thanks. Thank you so much. Lovely. Thank you.",
- "eventId": "devcon-7",
- "slot_start": 1731470400000,
- "slot_end": 1731471300000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/13ze8Pr4OxtxoFIIxGDV0SAGLb_aIJtknEOqxz5Ct5lA",
- "resources_slides": null,
- "speakers": [
- "siddharth-vaderaa"
- ]
- },
- "vector": [
0,
0,
0,
@@ -286369,7 +285844,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -286512,6 +285986,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -286664,7 +286139,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -287040,6 +286514,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -287093,6 +286568,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -287411,8 +286887,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -287589,9 +287063,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -287604,6 +287080,44 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "erc-4337-adoption-analysis",
+ "sourceId": "SGRFUA",
+ "title": "ERC-4337: Adoption Analysis",
+ "description": "Since the EntryPoint contract was deployed, millions of smart accounts have been created and UserOps submitted, via hundreds of exciting projects in the space. Join us as we look at the interesting trends onchain and the unique challenges and exciting opportunities faced by teams building in the space",
+ "track": "Usability",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Product",
+ "featured": true,
+ "doNotRecord": false,
+ "keywords": [
+ "ERC-4337"
+ ],
+ "tags": [
+ "DevRel",
+ "Use Cases",
+ "Account Abstraction",
+ "erc-4337",
+ "Account Abstraction",
+ "DevRel",
+ "Use Cases"
+ ],
+ "language": "en",
+ "speakers": [
+ "tom-teman"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731564000000,
+ "slot_end": 1731565800000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/17M-nImCJUoQMma2tumjGUf2IgWOapEl76FIQWV-y4XA"
+ },
+ "vector": [
0,
0,
0,
@@ -287612,6 +287126,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -287667,68 +287182,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0
- ]
- },
- {
- "session": {
- "id": "erc-3668-on-linea-built-in-trust-minimized-l2-to-l1-data-retrieval",
- "sourceId": "FARJAG",
- "title": "ERC-3668 on Linea: built-in, trust-minimized L2 to L1 data retrieval",
- "description": "ERC-3668 (aka. CCIP-read) enable L1 contracts to access Linea state. No special library need to be integrated, everything is built into the protocol and secured by Linea's zero-knowledge proofs. During this presentation, we will go into the details of how this works, the benefits and use cases you can start building today.",
- "track": "Layer 2",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Cross-chain"
- ],
- "tags": [
- "Layer 2s",
- "Zero-Knowledge"
- ],
- "language": "en",
- "speakers": [
- "julien"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731475800000,
- "slot_end": 1731477600000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1caoeThC6_UrDRFE2PQIcbIczFePi9G_E72Ud7YuJejc"
- },
- "vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -287851,6 +287304,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -287948,7 +287402,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -288465,6 +287918,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -288481,7 +287935,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -288493,6 +287946,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -288535,7 +287989,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -288577,6 +288030,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -288587,6 +288041,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -288975,11 +288430,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -288988,10 +288445,51 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "erigon-3-a-new-paradigm-for-ethereum-clients",
+ "sourceId": "CWZK8G",
+ "title": "Erigon 3 a New Paradigm for Ethereum Clients",
+ "description": "Erigon 3 represents a step change for Ethereum clients:\r\n\r\n* Modular client combining EL & CL\r\n* Transaction Centric\r\n* Deterministic storage model built to optimize EVM based chains\r\n* Performs on commodity drives\r\n* Sync model uses verifiable data replication and minimal re-execution\r\n* Acts as block consumer and producer, RPC, or indexer\r\n* Splits chain dissemination from chain distribution\r\n\r\nThis talk outlines the key features of Erigon 3 and explains how it will change Ethereum client landscape.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Product",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "efficiency",
+ "client",
+ "modular"
+ ],
+ "tags": [
+ "Architecture",
+ "Data Availability",
+ "Scalability",
+ "modular",
+ "Architecture",
+ "Data Availability",
+ "Scalability"
+ ],
+ "language": "en",
+ "speakers": [
+ "mark-holt"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731481200000,
+ "slot_end": 1731483000000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1AXdOVnj0u1_i9ZgFD0ao2vPGkVGyZU_aLbplEgtr5iY"
+ },
+ "vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -289030,11 +288528,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -289047,44 +288543,6 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "erc-4337-adoption-analysis",
- "sourceId": "SGRFUA",
- "title": "ERC-4337: Adoption Analysis",
- "description": "Since the EntryPoint contract was deployed, millions of smart accounts have been created and UserOps submitted, via hundreds of exciting projects in the space. Join us as we look at the interesting trends onchain and the unique challenges and exciting opportunities faced by teams building in the space",
- "track": "Usability",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Product",
- "featured": true,
- "doNotRecord": false,
- "keywords": [
- "ERC-4337"
- ],
- "tags": [
- "DevRel",
- "Use Cases",
- "Account Abstraction",
- "erc-4337",
- "Account Abstraction",
- "DevRel",
- "Use Cases"
- ],
- "language": "en",
- "speakers": [
- "tom-teman"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731564000000,
- "slot_end": 1731565800000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/17M-nImCJUoQMma2tumjGUf2IgWOapEl76FIQWV-y4XA"
- },
- "vector": [
0,
0,
0,
@@ -289093,7 +288551,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -289272,7 +288729,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -289339,6 +288795,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -289839,10 +289296,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -289888,7 +289347,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -290000,9 +289458,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -290011,7 +289466,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -290086,6 +289540,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -290340,6 +289795,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -290347,6 +289803,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -290355,10 +289812,60 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power",
+ "sourceId": "C3HTZP",
+ "title": "ETH++: A roadmap to (real) decentralization in a world of centralized power",
+ "description": "Unfortunately, trends in block building and MEV furnish rapid centralization pressures that erode the protocol guarantees we gather here to build for Ethereum. We must now define a roadmap to save proof-of-stake. This requires help from builders, transaction originators, protocol designers, and you. We will demistify the hype on how and if trusted hardware (TEEs) can help us decentralize. Let's focus on geographical diversity and permissionless designs, to bring the world together.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Community",
+ "featured": false,
+ "doNotRecord": false,
+ "tags": [
+ "Protocol Design",
+ "Censorship Resistance",
+ "Decentralization",
+ "MEV",
+ "Censorship Resistance",
+ "MEV",
+ "Protocol Design"
+ ],
+ "keywords": [
+ "TEE",
+ "hardware",
+ "decentralization"
+ ],
+ "duration": 1502,
+ "language": "en",
+ "sources_swarmHash": "f5b073402029914ebdac73cc6b507d7de61254e303ae0954496daf4736572e11",
+ "sources_youtubeId": "ySVYt6MUrHM",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a173a168eb53572b8a2.vtt",
+ "transcript_text": " Perfect. And in this talk we're going to cover kind of a bunch of different concepts at a pretty rapid fire pace. So we're going to start with how does ETH die? How does ETH go to zero? Why are we actually on the road for some possible futures in which this blockchain and this system, which we all love, just like doesn't do as well anymore. How can we save it? What is the formula for that? What does this have to do with E3, which I think is a meme you're going to be hearing a lot about in the next few months, few years, etc. What are the technologies we can use? We just heard about programming, privacy, and other things like that. What else can we do? What can you, the attendee here at DevCon and in the space, do to help this? And then what am I doing about all of this, and where do technologies like TEEs come in? So let's get right into it. I'm going to start a little bit funerary today. So I'm going to talk about what I consider to be the two most disturbing pictures in the Ethereum news cycle, the Ethereum space today, at least to me and to my dream of building a decentralized system together with you all. So the first one is from this paper called Regulating Decentralized Systems, Evidence from Sanctions on Tornado Cash, a paper published by the New York Federal Reserve, authors listed below. And in this paper, they go fairly deep into analyzing tornado cash and sanctions enforcement on decentralized blockchains, kind of enumerating various power dynamics, choke points, and other levers in the system, and then studying how effectively they can kind of manipulate these levers of power to do things like stop technologies they don't like. Technologies which, for example, many people here may have different feelings about. So, actually let me go back to that if I can figure out the clicker. Yeah, so an interesting thing about this picture is it shows the approach that as the nation-state game escalates, as we really go deep into this mission of decentralization, that various kind of centralized parties take on these things we build. And it's very simple. It's about control. It's about the boxes of control. And it's about how to leverage them and make sure we put as many X into these boxes that we see here as possible. So that's the first disturbing picture. The second one, so this is a graphic that you can go browse yourself online. The URL is up there. I can't read it from this distance, but benjdd.com slash AWS. There we go. And here you can go through the various different AWS data centers worldwide and kind of view different AWS to AWS latency pictures. In a very real world, this is the topology of the internet, of the networks on which we're building our technologies today. So you can see on the left there, you have US East 1, which is the most popular AWS data center for crypto deployments. And the lighter the color, or sorry, I guess they changed the color scheme, but I think the blue lines are things that are like approximately on the order of under 400 milliseconds. The light blue line is kind of, or maybe it's under 200, and the light blue line is over 200, etc. But you can see there are these very clear corridors of latency and power that we've built. Why is that? Well, because that is where the data centers are. That is where the economic activity is. That is where, in many cases, the users are. That is where companies want to have their servers and want to build their infrastructure. That is where the capital is and the investors and all of these pieces of the puzzle. And so we've built a power overlay using the latency structure of the Internet on top of that. And this is what it looks like. So we exist in a world where there are two fundamental realities. The first one is that much of the world's power is already centralized. That includes military power, economic power, geopolitical power, social power, and more. And on top of that, the disturbing trend is that centralization begets more centralization. So centralization is an accelerationist loop onto itself. This is present in markets through phenomena like economies of scale or winner-takes-all. It's present in zero-sum games such as trading. It's present in auctions, etc. So when you have one sort of centralizing vector, that tends to bring all sorts of centralization into various aspects of your system, something we really want to avoid if, as we said before, deconstructing the nation-state is at all on the radar for this project. So what I would say, that given that we are in these situations, we have to stop YOLOing protocol proposals and upgrades in terms of this power dynamic and this topology on which we exist, and instead we have to start treating distribution of power globally as a first-class goal for the next chapter of ETH. How can we be intentional about where we're pushing power in the system? This is much, much more important than the performance of the system. Fast block times, throughput, latency, anything like that. Because if you have those things without having distributed power, you've essentially just reinvented the systems that we were trying to escape this whole time. Those performance systems already exist. Otherwise, we come back to the reality where much of the world is centralized and centralization begets centralization. So instead of that, let's stop YOLOing protocol proposals and treat distribution of power globally as a first-class goal in E3. Okay, I'm gonna exit the infinite loop and instead go to the infinite garden. So this is an actual picture of my grandmother growing her own infinite garden. And I think the solution, the exit to this loop, is planting our own gardens, building our own systems. So let us all together kind of brainstorm this infinite garden of power distribution and think about very intentionally, carefully, and together about where we want power to go. I'm going to give you one troll idea, and I'm sure you're going to hear many more over the next few weeks, but this is going to be E3 done my way. This is the best hatching gif I could find that was free. Shout out Wikimedia Foundation, but it is very cute. All right. So in my opinion, these are the four pillars of E3 as I see it. And I say pillars because these are actually non-negotiable properties. If either of these four things, any of these four things are compromised on, we will fail to achieve the goals of cryptocurrency. We will fail to achieve the goals of Ethereum. And as I said in the beginning of the talk, the price will obviously be zero, regardless how much institutional interests or ETFs or et cetera we're able to create. So these four pillars, as far as I see them, number one pillar is permissionless. And I'm going to explain each of these in greater depth. Number two is distributed from a technical perspective and a computational perspective. Number three, and this is the most important property by far, is geo-economically decentralized. And we're going to define that very carefully shortly. And number four is neutral builder efficient. So what are these pillars? Let's get into it. Well, the first one is permissionlessness. This is something we should all have at least a little bit of context on in this space. But specifically, I slice it with thinking about MEV and how MEV is expressed in the protocol, because that's what I work on. So for me, what permissionlessness means is that any actor is able to express their value or preference into a block at any point in the block construction process. And that value is able to percolate to be expressed through the process and into the system. You might note that this is actually the same as many definitions of censorship resistance. Essentially, if you pay a fee, you get in as one slicing, although there's a lot of kind of details there. Okay, other than permission lists, we must also make E3 distributed. So this one is pretty obvious too. This means taking computations that right now require one big computer or one big server and breaking them down into small pieces that we can then distribute kind of all over the network and all over the world. Without doing this, it's hard to imagine how to decentralize. If you require a huge computer to do everything in one central place, that's inherently not decentralized. All right. This property, as I said, is the most important, geoeconomic decentralization. I'll spend a little longer on it. So this specifically is a very specific notion of geoeconomic decentralization, saying that co-location in the protocol must yield minimal additional profit. So this is not saying, hey, we have a node in France and a node in the U.S. It's not saying, hey, we're on three of these AWS topologies of power. We're on three of these links, or five. That is not geoeconomic decentralization. Geoeconomic decentralization is saying that there's a level playing field in your system for people who are participating outside of those existing corridors of power, outside of those existing latency links, outside of that game theory we've created with AWS. And those people must be able to participate as profitably and as meaningfully as the people who are sitting in New York, as the people who are sitting in Japan, co-located with Binance, and et cetera. If you reduce the participation of those systems in the network, in the iterated game, as time passes, your network collapses to these central points of geography and power, and then you lose any hope at censorship resistance or any of the other properties you want. All right, so those properties sound great. Can we actually build that? Well, this is my troll roadmap to get there. It's a little bit oversimplified, but hopefully it communicates the point. So I believe right now, standing from today, there are two things or kind of two broad pushes I want to work on. The first is to TEFI everything. Why TEFI? Well, we're going to get more into that in a second. But basically, TEEs allow us to distribute the computation. So remember when we said before the one big computer becomes many small computers? TEEs give you the trust APIs to make that possible with untrusted parties operating these small computers. And once you have this distribution, you don't have decentralization yet, but at least you're able to start pushing this infrastructure and pushing the power to the edges of your network and outside of those lines of AWS, those lines of power that we have today. So after we TEify everything, we have to start in a cycle doing two things. The first is pushing this power to the edge. As we deconstruct the computation, as we modularize it, we push. And then the second thing is also to reduce the power of actually TEs in our system. So TEs are not a silver bullet. They're not a magical solution to everything. They give a lot of power in the system to Intel. They take it away from that graph that I showed you earlier with AWS and move the needle a little bit more right now towards Intel and NVIDIA and AMD and other hardware manufacturers. So while I would argue that's better than only having kind of trad-fi latency corridors determine the evolution of our network, it's still not perfect, right? And there's a lot we can do using other cryptography, including what we've heard on the panel before, using other alternative TE approaches, open TEEs, things like that, to sort of remove power from the TE itself as well. So I think it's a two-track approach. Once we have the platform to distribute and push things to the edges, we then have to actually start pushing things to those edges, and I'm going to cover how you all can help with that shortly, but also start kind of eroding that core power that we've now built up in moving this needle to this other party which is Intel so I'm going to ask for your help please so please give me your arms or if you don't have arms just your body give me your soul sounded kind of dystopian so I'm not going to ask for your soul but please give me your help in this and how can you all help with this well if you're a dap developer if you this? Well, if you're a dApp developer, if you're an infrastructure developer, if you're a user, ask yourself, how can we, for our uses, what we're doing, what we're using the protocol for, how can we get power off of these corridors of power that we see here? Can we use endpoints that are in different locations? Do they meet our needs? Can we deploy our server somewhere that geographically makes sense for the change we're trying to create in the world, rather than defaulting to US East 1 on AWS because it's the first thing that happens when you click launch? Are we able to make that change as a space? I think everyone needs to spend some time thinking about what am I doing, and is it actually helping centralize power onto these power corridors, or is it actually helping push power out to the edges which is what actually underlies the long-term value of decentralization and cooperation and even the price yes okay so going back to this graph well one obvious thing you might just say is oh we have many boxes why not just have many of them just sign or have some sort of list where the proposer is forced to sign? Well, the reason is very simple because it doesn't actually solve the power distribution problem. It's not a meaningful solution to censorship in any way, right? If in your metagame you collapse to a state where the system itself is very centralized, no form of technical paper mache, technical decentralization, etc., even though it feels really good to us as technologists, it feels great to just say like, hey, we can just do this and it solves the problem. Does it? I mean, let's think about it for a second. So certainly on Binance Smart Chain, it would not. And in general, what I would say is censorship and power dynamics and the way our money works, these are political problems. We're not going to tech tree our way out of these problems. We need to have deeper conversations about where the power is in our network, where we're building power in our network, and how we iterate that towards a place that works better for us. That being said, that doesn't mean that as technologists we can do nothing. Our job is not to make it worse. So please also help me in that if you're participating in this space. Do not centralize power back to those corridors. And remember, today we already live in a world where much of the world's power is centralized, and centralization begets centralization. So I think this is really existential to ETH. We're at the point where we have a choice as a community of do we start pushing the power we've built out outside of AWS or do we concentrate it seeking ETF inflows, seeking stock exchange listings, seeking trad-fi participation, and concentrate the system to the very corridors of power that we thought we were disrupting. So to get actual decentralization, well, the definition is very simple. It's how much have you pushed this to the edges? And I wish it was something that could be easily quantified, but unfortunately it's not, and that's just something we have to live with. A few more things I have to say. So the first is, this is a little bit spicy and a little trolly. I think we should reject the Ethereum endgame. So the Ethereum endgame, for those who know it specifically, is a slightly older, probably like somewhat out of date post, so I'm kind of attacking a straw man here, basically saying that like, hey, is it really that bad if we have these big centralized machines doing things specifically for MEV, but then we kind of keep them honest with the rest of the network. We keep that lightweight and everything. I think that's defeatism personally. I think we can decentralize all the things, and I think as long as you have a central corridor of power, a central source of concentrated power, any sort of system on top is not going to be able to meaningfully police or control it. So we need to actually decentralize all the things that require the big machines as well. Doing a deeper dive into how this relates to censorship resistance. So censorship resistance is a very interesting topic. Traditionally in the academic space, it says that if you create a transaction that assume you pay the fees, you'll be included within some number of blocks. That number is called delta. It's called the censorship resistance or synchrony parameter. So one question I have for us as a protocol is what delta do we actually need and how do we value various deltas in the protocol against other properties we care about, like power distribution, kind of geographic decentralization, et cetera. Because as you push delta to zero, you actually get fair ordering out of the censorship resistance definition, right? If you need to be included immediately, as soon as your transaction is sent, well, what does that mean for the person that's on the other side of the world? How does that stack up with them? What if your delta is below the network limit? How does that then get resolved into the protocol? How do we weigh collapsing these trade-offs against other centralizing effects we can create in the MEV space that maybe help us build this robust geopolitical base and actually allow us to push power back into the edges. So I think the most dangerous thing the space can do right now is essentially fetishize and chase one-block censorship resistance at the expense of all of the core properties that will actually provide geopolitical robustness and censorship resistance in the long term. I think we haven't had a conversation in the community about how to weigh those two things together. So let's do that, please, before we start YOLOing protocol updates. And let's do that in a way that addresses this approach to censoring our networks. So what we need for decentralization is real global meaningful distribution of power. That sounds great, Phil. But we all know there's certain things standing in the way of that. So the first one is what I call UX fentanyl. This is a Web 2 mentality that you need to make things faster and more addictive for your users. If your users aren't addicted, if they're not running on your treadmill, if they're not generating returns, you failed, you're a bad person, you're a bad founder. No, that's not the way we build Web3 applications, I'm sorry. If you chase UX fentanyl, you chase the dragon over and over and over again to the end state. Well, now you need 50 milliseconds, now you need 10 milliseconds, now the mind can perceive five milliseconds. We've gone down that path in web two, and we've ended up with users that can't meaningfully interact with the technology. These zombies that just are kind of fed these inputs, right? How many people like that here? Nobody likes it, right? So let's stop that shit in web three, please. Enough. Yeah, seriously. Another one I want to talk about, and this is a little bit mean to the EF, so I feel a little bit bad whenever I talk about this, but napkin research. And I tried to choose a slightly fancier napkin this time instead of like a dirty napkin or something. But I think we do a lot of our research discussions very informally and without even having deep conversations about what are principles? What does censorship resistance mean to us? What does this protocol change mean? How do you define it i think we can do a lot more i've written a blog post about a few ideas i have but i'd love to talk to people because i think the problem with napkin research is when you have a room this big the napkins become a flood and it becomes too easy to lobby too easy to capture the process too easy to get kind of yO protocol upgrades and bad ideas shipped into the L1 we all care about. So let's kind of upgrade our napkin. The problem is if you combine napkin research with UX fentanyl, that's a pretty bad situation. So that I think is how ETH goes to zero. It's the combination of napkin research and UX fentanyl, eroding the decentralization we've built so carefully and leaving us open to capture, to co-opting, and to rebuilding the systems we sought to evade. So in all of that, the exit must be globally distributed power. There is no alternative. The alternative is $0 ETH. Say it again and again and again, please, in the mirror. Let's move beyond the napkin. This is a table that I have from a talk I gave at ETH Denver. I encourage you to look it up. It talks about all the technologies that we have, including, as we talked about, kind of programmable encryption and their various trade-offs for deploying in these contexts that we have in distributed protocols, including who would break them, including rent privileges, including geographic decentralization, which I think is the most important row here. We need to jam more about this and fill this table out more. Unfortunately, I don't have time to go deep today, but please check it out and let's discuss more. Okay, I'm going to leave you with one soundbite. Why TEEs? Well, they give us the theoretical maximal performance for taking all of these monolithic things we have and distributing them so we can push to the edges and at least for what I care about which is the MEV context we can iterate the security there and for your DAP if you want to do this the recipe is simple build demand distribute the infra to where your demand exists natively to it and then scale your network from there. As for what Flashbots is doing, we're doing so many different things in terms of TE-fying everything, pushing it to the edges, creating platforms for you all to push things to the edges more. There's a lot that's going to be coming out in the next few weeks, so the only thing I can ask is for you to stay tuned or find me later. And please don't forget that I need your arms so that we can get out of this power dystopia. All right, thank you very much, everyone. All right, Philip. Well, well, well. Napkin, fentanyl, and arms. That's quite a fascinating presentation. But nevertheless, let's go right through our Q&A. We've got about four minutes left. Is there any value to centralization at all? Or do you believe everything in life should be decentralized? What do you think, Philip? Yeah, I mean, I think, for example, government is fundamentally centralized, right? And many people find that valuable in many contexts. I think, you know, like for example my laptop is like a centralized computing hub for myself. I don't necessarily want to decentralize that. I think it really depends on the application. I think decentralization is useful where you want cooperation across differences and that's actually where the power and censorship resistance comes from. The more different people that are cooperating under the same tent, and the more each one walks away feeling like, yes, that was fair, that was a just outcome, the more robustness, the more censorship resistance you get for free. And so I think in those cases, it's not centralization is harmful. But in other cases, it totally does make sense. Excellent. Thank you very much. All right. I see people voting and up voting the up voting the questions right at the top with five votes TES are peak centralization three US companies a local device ZKs a viable alternative take it away yeah so we can have a deeper conversation about ZKs ZKs don't allow for the kind of like interactive group computation that you need to do in a lot of consensus protocols or for example MEV or transaction processing. So maybe like kind of at the edges of like, okay, if I show you a proof, maybe you can run this more limited algorithm. Yes, but at the core, it's not really the same tech or the same abstraction. I think all of the entries in that table, ZK, MPC, FHE, TEs, et cetera, crypto economics, they can all chisel away at the centralization. So it's all about using which one is appropriate for your app. Maybe your app is already centralized. Maybe it doesn't need geo-decentralization. Then why would you use a TE, right, et cetera? So I think it's about putting as much as possible off TEs and making TEs also able to be kind of more trusted by having open TEEs and things like that in the future. But yeah, it is a centralization risk for sure. All right, excellent question, excellent answer. How do you think centralization risk of staking compares to the rest of your pillars? I'm not sure what centralization risk of staking means if it means like basically the stake set becoming more centralized or the fact that staking exists centralizing the coin supply I think there's many like slices of staking and centralization I think yes it is kind of implied by the rest of my pillars in my world view like if we have permissionlessness and distribution and specifically geo-decentralization where it's fair for you to participate no matter where you stake, I think you get less stake centralization. So I would say for me it's like downstream of the pillars. If you want to slice it there, I think it is a totally valid thing to have on the table. Say like we don't want centralization into the stake set all right we got one minute more let's try one last question with six upvotes te solve every problem that was previously described in the programmable cryptography session why aren't more people promoting them not only do they solve all the problems but you can use them together to give you defense in depth to give you various optimizations and things like that we're building like a lot of stacks to help people do that. So I think a lot of people are promoting them. I think people are afraid. I think people in crypto and in life and in general, they love binaries. Either TEs are broken and they're useless, they're garbage, we need to burn them down, or they're the best thing ever. And they cast every opinion on TE into one of these two buckets, the reality is much more nuanced. They make sense for a lot of applications. They don't for many others. I think people are promoting and using them and seeing success using them actually basically everywhere they make sense. So I do think you will see more people promoting and using them over time. Definitely in time to come. Ladies and gentlemen, let's give our speaker another big, big round of applause. Thanks, everyone.",
+ "eventId": "devcon-7",
+ "slot_start": 1731403800000,
+ "slot_end": 1731405600000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1bcWYCRlknrhBAHOizptWAGujiHHrSU_sAh9xh-oi1js",
+ "resources_slides": null,
+ "speakers": [
+ "philip-daian"
+ ]
+ },
+ "vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -290400,13 +289907,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -290415,51 +289920,10 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "erigon-3-a-new-paradigm-for-ethereum-clients",
- "sourceId": "CWZK8G",
- "title": "Erigon 3 a New Paradigm for Ethereum Clients",
- "description": "Erigon 3 represents a step change for Ethereum clients:\r\n\r\n* Modular client combining EL & CL\r\n* Transaction Centric\r\n* Deterministic storage model built to optimize EVM based chains\r\n* Performs on commodity drives\r\n* Sync model uses verifiable data replication and minimal re-execution\r\n* Acts as block consumer and producer, RPC, or indexer\r\n* Splits chain dissemination from chain distribution\r\n\r\nThis talk outlines the key features of Erigon 3 and explains how it will change Ethereum client landscape.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Product",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "efficiency",
- "client",
- "modular"
- ],
- "tags": [
- "Architecture",
- "Data Availability",
- "Scalability",
- "modular",
- "Architecture",
- "Data Availability",
- "Scalability"
- ],
- "language": "en",
- "speakers": [
- "mark-holt"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731481200000,
- "slot_end": 1731483000000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1AXdOVnj0u1_i9ZgFD0ao2vPGkVGyZU_aLbplEgtr5iY"
- },
- "vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -290708,6 +290172,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -290766,7 +290231,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -291148,6 +290612,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -291191,6 +290656,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -291246,6 +290712,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -291269,12 +290736,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -291293,6 +290758,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -291347,7 +290813,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -291514,7 +290979,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -291707,6 +291171,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -291715,6 +291180,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -291722,12 +291188,56 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "eth-arauca-emersons-legacy-and-the-hope-for-change-in-vulnerable-communities-through-ethereum",
+ "sourceId": "TA3N8E",
+ "title": "ETH Arauca: Emerson's Legacy and the Hope for Change in Vulnerable Communities Through Ethereum",
+ "description": "In this talk, we will explore the moving case of ETH Arauca and the brave young activist Emerson, who led the ETH Colombia node and whose life was tragically taken in the exercise of his mission. We will analyze how Ethereum, through its vision of decentralized finance, can act as an engine of transformation in vulnerable communities with conflict contexts. This talk seeks to give visibility to Emerson's legacy, ETH leaders challenges, and highlight the potential of Ethereum to drive real change",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "Ethereum",
+ "for",
+ "Good"
+ ],
+ "tags": [
+ "Decentralization",
+ "Local Impact",
+ "Social Recovery",
+ "ethereum",
+ "good",
+ "Decentralization",
+ "Local Impact",
+ "Social Recovery"
+ ],
+ "language": "en",
+ "speakers": [
+ "andres-forigua",
+ "william-martinez",
+ "mateo-sabogal"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731660600000,
+ "slot_end": 1731661200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1nM9AZTRUu_izRLyWBvXZg8c-yplG6h0ED_v5As56vgk"
+ },
+ "vector": [
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -291768,7 +291278,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -291776,7 +291285,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -291785,60 +291293,10 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "eth-a-roadmap-to-real-decentralization-in-a-world-of-centralized-power",
- "sourceId": "C3HTZP",
- "title": "ETH++: A roadmap to (real) decentralization in a world of centralized power",
- "description": "Unfortunately, trends in block building and MEV furnish rapid centralization pressures that erode the protocol guarantees we gather here to build for Ethereum. We must now define a roadmap to save proof-of-stake. This requires help from builders, transaction originators, protocol designers, and you. We will demistify the hype on how and if trusted hardware (TEEs) can help us decentralize. Let's focus on geographical diversity and permissionless designs, to bring the world together.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Community",
- "featured": false,
- "doNotRecord": false,
- "tags": [
- "Protocol Design",
- "Censorship Resistance",
- "Decentralization",
- "MEV",
- "Censorship Resistance",
- "MEV",
- "Protocol Design"
- ],
- "keywords": [
- "TEE",
- "hardware",
- "decentralization"
- ],
- "duration": 1502,
- "language": "en",
- "sources_swarmHash": "f5b073402029914ebdac73cc6b507d7de61254e303ae0954496daf4736572e11",
- "sources_youtubeId": "ySVYt6MUrHM",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a173a168eb53572b8a2.vtt",
- "transcript_text": " Perfect. And in this talk we're going to cover kind of a bunch of different concepts at a pretty rapid fire pace. So we're going to start with how does ETH die? How does ETH go to zero? Why are we actually on the road for some possible futures in which this blockchain and this system, which we all love, just like doesn't do as well anymore. How can we save it? What is the formula for that? What does this have to do with E3, which I think is a meme you're going to be hearing a lot about in the next few months, few years, etc. What are the technologies we can use? We just heard about programming, privacy, and other things like that. What else can we do? What can you, the attendee here at DevCon and in the space, do to help this? And then what am I doing about all of this, and where do technologies like TEEs come in? So let's get right into it. I'm going to start a little bit funerary today. So I'm going to talk about what I consider to be the two most disturbing pictures in the Ethereum news cycle, the Ethereum space today, at least to me and to my dream of building a decentralized system together with you all. So the first one is from this paper called Regulating Decentralized Systems, Evidence from Sanctions on Tornado Cash, a paper published by the New York Federal Reserve, authors listed below. And in this paper, they go fairly deep into analyzing tornado cash and sanctions enforcement on decentralized blockchains, kind of enumerating various power dynamics, choke points, and other levers in the system, and then studying how effectively they can kind of manipulate these levers of power to do things like stop technologies they don't like. Technologies which, for example, many people here may have different feelings about. So, actually let me go back to that if I can figure out the clicker. Yeah, so an interesting thing about this picture is it shows the approach that as the nation-state game escalates, as we really go deep into this mission of decentralization, that various kind of centralized parties take on these things we build. And it's very simple. It's about control. It's about the boxes of control. And it's about how to leverage them and make sure we put as many X into these boxes that we see here as possible. So that's the first disturbing picture. The second one, so this is a graphic that you can go browse yourself online. The URL is up there. I can't read it from this distance, but benjdd.com slash AWS. There we go. And here you can go through the various different AWS data centers worldwide and kind of view different AWS to AWS latency pictures. In a very real world, this is the topology of the internet, of the networks on which we're building our technologies today. So you can see on the left there, you have US East 1, which is the most popular AWS data center for crypto deployments. And the lighter the color, or sorry, I guess they changed the color scheme, but I think the blue lines are things that are like approximately on the order of under 400 milliseconds. The light blue line is kind of, or maybe it's under 200, and the light blue line is over 200, etc. But you can see there are these very clear corridors of latency and power that we've built. Why is that? Well, because that is where the data centers are. That is where the economic activity is. That is where, in many cases, the users are. That is where companies want to have their servers and want to build their infrastructure. That is where the capital is and the investors and all of these pieces of the puzzle. And so we've built a power overlay using the latency structure of the Internet on top of that. And this is what it looks like. So we exist in a world where there are two fundamental realities. The first one is that much of the world's power is already centralized. That includes military power, economic power, geopolitical power, social power, and more. And on top of that, the disturbing trend is that centralization begets more centralization. So centralization is an accelerationist loop onto itself. This is present in markets through phenomena like economies of scale or winner-takes-all. It's present in zero-sum games such as trading. It's present in auctions, etc. So when you have one sort of centralizing vector, that tends to bring all sorts of centralization into various aspects of your system, something we really want to avoid if, as we said before, deconstructing the nation-state is at all on the radar for this project. So what I would say, that given that we are in these situations, we have to stop YOLOing protocol proposals and upgrades in terms of this power dynamic and this topology on which we exist, and instead we have to start treating distribution of power globally as a first-class goal for the next chapter of ETH. How can we be intentional about where we're pushing power in the system? This is much, much more important than the performance of the system. Fast block times, throughput, latency, anything like that. Because if you have those things without having distributed power, you've essentially just reinvented the systems that we were trying to escape this whole time. Those performance systems already exist. Otherwise, we come back to the reality where much of the world is centralized and centralization begets centralization. So instead of that, let's stop YOLOing protocol proposals and treat distribution of power globally as a first-class goal in E3. Okay, I'm gonna exit the infinite loop and instead go to the infinite garden. So this is an actual picture of my grandmother growing her own infinite garden. And I think the solution, the exit to this loop, is planting our own gardens, building our own systems. So let us all together kind of brainstorm this infinite garden of power distribution and think about very intentionally, carefully, and together about where we want power to go. I'm going to give you one troll idea, and I'm sure you're going to hear many more over the next few weeks, but this is going to be E3 done my way. This is the best hatching gif I could find that was free. Shout out Wikimedia Foundation, but it is very cute. All right. So in my opinion, these are the four pillars of E3 as I see it. And I say pillars because these are actually non-negotiable properties. If either of these four things, any of these four things are compromised on, we will fail to achieve the goals of cryptocurrency. We will fail to achieve the goals of Ethereum. And as I said in the beginning of the talk, the price will obviously be zero, regardless how much institutional interests or ETFs or et cetera we're able to create. So these four pillars, as far as I see them, number one pillar is permissionless. And I'm going to explain each of these in greater depth. Number two is distributed from a technical perspective and a computational perspective. Number three, and this is the most important property by far, is geo-economically decentralized. And we're going to define that very carefully shortly. And number four is neutral builder efficient. So what are these pillars? Let's get into it. Well, the first one is permissionlessness. This is something we should all have at least a little bit of context on in this space. But specifically, I slice it with thinking about MEV and how MEV is expressed in the protocol, because that's what I work on. So for me, what permissionlessness means is that any actor is able to express their value or preference into a block at any point in the block construction process. And that value is able to percolate to be expressed through the process and into the system. You might note that this is actually the same as many definitions of censorship resistance. Essentially, if you pay a fee, you get in as one slicing, although there's a lot of kind of details there. Okay, other than permission lists, we must also make E3 distributed. So this one is pretty obvious too. This means taking computations that right now require one big computer or one big server and breaking them down into small pieces that we can then distribute kind of all over the network and all over the world. Without doing this, it's hard to imagine how to decentralize. If you require a huge computer to do everything in one central place, that's inherently not decentralized. All right. This property, as I said, is the most important, geoeconomic decentralization. I'll spend a little longer on it. So this specifically is a very specific notion of geoeconomic decentralization, saying that co-location in the protocol must yield minimal additional profit. So this is not saying, hey, we have a node in France and a node in the U.S. It's not saying, hey, we're on three of these AWS topologies of power. We're on three of these links, or five. That is not geoeconomic decentralization. Geoeconomic decentralization is saying that there's a level playing field in your system for people who are participating outside of those existing corridors of power, outside of those existing latency links, outside of that game theory we've created with AWS. And those people must be able to participate as profitably and as meaningfully as the people who are sitting in New York, as the people who are sitting in Japan, co-located with Binance, and et cetera. If you reduce the participation of those systems in the network, in the iterated game, as time passes, your network collapses to these central points of geography and power, and then you lose any hope at censorship resistance or any of the other properties you want. All right, so those properties sound great. Can we actually build that? Well, this is my troll roadmap to get there. It's a little bit oversimplified, but hopefully it communicates the point. So I believe right now, standing from today, there are two things or kind of two broad pushes I want to work on. The first is to TEFI everything. Why TEFI? Well, we're going to get more into that in a second. But basically, TEEs allow us to distribute the computation. So remember when we said before the one big computer becomes many small computers? TEEs give you the trust APIs to make that possible with untrusted parties operating these small computers. And once you have this distribution, you don't have decentralization yet, but at least you're able to start pushing this infrastructure and pushing the power to the edges of your network and outside of those lines of AWS, those lines of power that we have today. So after we TEify everything, we have to start in a cycle doing two things. The first is pushing this power to the edge. As we deconstruct the computation, as we modularize it, we push. And then the second thing is also to reduce the power of actually TEs in our system. So TEs are not a silver bullet. They're not a magical solution to everything. They give a lot of power in the system to Intel. They take it away from that graph that I showed you earlier with AWS and move the needle a little bit more right now towards Intel and NVIDIA and AMD and other hardware manufacturers. So while I would argue that's better than only having kind of trad-fi latency corridors determine the evolution of our network, it's still not perfect, right? And there's a lot we can do using other cryptography, including what we've heard on the panel before, using other alternative TE approaches, open TEEs, things like that, to sort of remove power from the TE itself as well. So I think it's a two-track approach. Once we have the platform to distribute and push things to the edges, we then have to actually start pushing things to those edges, and I'm going to cover how you all can help with that shortly, but also start kind of eroding that core power that we've now built up in moving this needle to this other party which is Intel so I'm going to ask for your help please so please give me your arms or if you don't have arms just your body give me your soul sounded kind of dystopian so I'm not going to ask for your soul but please give me your help in this and how can you all help with this well if you're a dap developer if you this? Well, if you're a dApp developer, if you're an infrastructure developer, if you're a user, ask yourself, how can we, for our uses, what we're doing, what we're using the protocol for, how can we get power off of these corridors of power that we see here? Can we use endpoints that are in different locations? Do they meet our needs? Can we deploy our server somewhere that geographically makes sense for the change we're trying to create in the world, rather than defaulting to US East 1 on AWS because it's the first thing that happens when you click launch? Are we able to make that change as a space? I think everyone needs to spend some time thinking about what am I doing, and is it actually helping centralize power onto these power corridors, or is it actually helping push power out to the edges which is what actually underlies the long-term value of decentralization and cooperation and even the price yes okay so going back to this graph well one obvious thing you might just say is oh we have many boxes why not just have many of them just sign or have some sort of list where the proposer is forced to sign? Well, the reason is very simple because it doesn't actually solve the power distribution problem. It's not a meaningful solution to censorship in any way, right? If in your metagame you collapse to a state where the system itself is very centralized, no form of technical paper mache, technical decentralization, etc., even though it feels really good to us as technologists, it feels great to just say like, hey, we can just do this and it solves the problem. Does it? I mean, let's think about it for a second. So certainly on Binance Smart Chain, it would not. And in general, what I would say is censorship and power dynamics and the way our money works, these are political problems. We're not going to tech tree our way out of these problems. We need to have deeper conversations about where the power is in our network, where we're building power in our network, and how we iterate that towards a place that works better for us. That being said, that doesn't mean that as technologists we can do nothing. Our job is not to make it worse. So please also help me in that if you're participating in this space. Do not centralize power back to those corridors. And remember, today we already live in a world where much of the world's power is centralized, and centralization begets centralization. So I think this is really existential to ETH. We're at the point where we have a choice as a community of do we start pushing the power we've built out outside of AWS or do we concentrate it seeking ETF inflows, seeking stock exchange listings, seeking trad-fi participation, and concentrate the system to the very corridors of power that we thought we were disrupting. So to get actual decentralization, well, the definition is very simple. It's how much have you pushed this to the edges? And I wish it was something that could be easily quantified, but unfortunately it's not, and that's just something we have to live with. A few more things I have to say. So the first is, this is a little bit spicy and a little trolly. I think we should reject the Ethereum endgame. So the Ethereum endgame, for those who know it specifically, is a slightly older, probably like somewhat out of date post, so I'm kind of attacking a straw man here, basically saying that like, hey, is it really that bad if we have these big centralized machines doing things specifically for MEV, but then we kind of keep them honest with the rest of the network. We keep that lightweight and everything. I think that's defeatism personally. I think we can decentralize all the things, and I think as long as you have a central corridor of power, a central source of concentrated power, any sort of system on top is not going to be able to meaningfully police or control it. So we need to actually decentralize all the things that require the big machines as well. Doing a deeper dive into how this relates to censorship resistance. So censorship resistance is a very interesting topic. Traditionally in the academic space, it says that if you create a transaction that assume you pay the fees, you'll be included within some number of blocks. That number is called delta. It's called the censorship resistance or synchrony parameter. So one question I have for us as a protocol is what delta do we actually need and how do we value various deltas in the protocol against other properties we care about, like power distribution, kind of geographic decentralization, et cetera. Because as you push delta to zero, you actually get fair ordering out of the censorship resistance definition, right? If you need to be included immediately, as soon as your transaction is sent, well, what does that mean for the person that's on the other side of the world? How does that stack up with them? What if your delta is below the network limit? How does that then get resolved into the protocol? How do we weigh collapsing these trade-offs against other centralizing effects we can create in the MEV space that maybe help us build this robust geopolitical base and actually allow us to push power back into the edges. So I think the most dangerous thing the space can do right now is essentially fetishize and chase one-block censorship resistance at the expense of all of the core properties that will actually provide geopolitical robustness and censorship resistance in the long term. I think we haven't had a conversation in the community about how to weigh those two things together. So let's do that, please, before we start YOLOing protocol updates. And let's do that in a way that addresses this approach to censoring our networks. So what we need for decentralization is real global meaningful distribution of power. That sounds great, Phil. But we all know there's certain things standing in the way of that. So the first one is what I call UX fentanyl. This is a Web 2 mentality that you need to make things faster and more addictive for your users. If your users aren't addicted, if they're not running on your treadmill, if they're not generating returns, you failed, you're a bad person, you're a bad founder. No, that's not the way we build Web3 applications, I'm sorry. If you chase UX fentanyl, you chase the dragon over and over and over again to the end state. Well, now you need 50 milliseconds, now you need 10 milliseconds, now the mind can perceive five milliseconds. We've gone down that path in web two, and we've ended up with users that can't meaningfully interact with the technology. These zombies that just are kind of fed these inputs, right? How many people like that here? Nobody likes it, right? So let's stop that shit in web three, please. Enough. Yeah, seriously. Another one I want to talk about, and this is a little bit mean to the EF, so I feel a little bit bad whenever I talk about this, but napkin research. And I tried to choose a slightly fancier napkin this time instead of like a dirty napkin or something. But I think we do a lot of our research discussions very informally and without even having deep conversations about what are principles? What does censorship resistance mean to us? What does this protocol change mean? How do you define it i think we can do a lot more i've written a blog post about a few ideas i have but i'd love to talk to people because i think the problem with napkin research is when you have a room this big the napkins become a flood and it becomes too easy to lobby too easy to capture the process too easy to get kind of yO protocol upgrades and bad ideas shipped into the L1 we all care about. So let's kind of upgrade our napkin. The problem is if you combine napkin research with UX fentanyl, that's a pretty bad situation. So that I think is how ETH goes to zero. It's the combination of napkin research and UX fentanyl, eroding the decentralization we've built so carefully and leaving us open to capture, to co-opting, and to rebuilding the systems we sought to evade. So in all of that, the exit must be globally distributed power. There is no alternative. The alternative is $0 ETH. Say it again and again and again, please, in the mirror. Let's move beyond the napkin. This is a table that I have from a talk I gave at ETH Denver. I encourage you to look it up. It talks about all the technologies that we have, including, as we talked about, kind of programmable encryption and their various trade-offs for deploying in these contexts that we have in distributed protocols, including who would break them, including rent privileges, including geographic decentralization, which I think is the most important row here. We need to jam more about this and fill this table out more. Unfortunately, I don't have time to go deep today, but please check it out and let's discuss more. Okay, I'm going to leave you with one soundbite. Why TEEs? Well, they give us the theoretical maximal performance for taking all of these monolithic things we have and distributing them so we can push to the edges and at least for what I care about which is the MEV context we can iterate the security there and for your DAP if you want to do this the recipe is simple build demand distribute the infra to where your demand exists natively to it and then scale your network from there. As for what Flashbots is doing, we're doing so many different things in terms of TE-fying everything, pushing it to the edges, creating platforms for you all to push things to the edges more. There's a lot that's going to be coming out in the next few weeks, so the only thing I can ask is for you to stay tuned or find me later. And please don't forget that I need your arms so that we can get out of this power dystopia. All right, thank you very much, everyone. All right, Philip. Well, well, well. Napkin, fentanyl, and arms. That's quite a fascinating presentation. But nevertheless, let's go right through our Q&A. We've got about four minutes left. Is there any value to centralization at all? Or do you believe everything in life should be decentralized? What do you think, Philip? Yeah, I mean, I think, for example, government is fundamentally centralized, right? And many people find that valuable in many contexts. I think, you know, like for example my laptop is like a centralized computing hub for myself. I don't necessarily want to decentralize that. I think it really depends on the application. I think decentralization is useful where you want cooperation across differences and that's actually where the power and censorship resistance comes from. The more different people that are cooperating under the same tent, and the more each one walks away feeling like, yes, that was fair, that was a just outcome, the more robustness, the more censorship resistance you get for free. And so I think in those cases, it's not centralization is harmful. But in other cases, it totally does make sense. Excellent. Thank you very much. All right. I see people voting and up voting the up voting the questions right at the top with five votes TES are peak centralization three US companies a local device ZKs a viable alternative take it away yeah so we can have a deeper conversation about ZKs ZKs don't allow for the kind of like interactive group computation that you need to do in a lot of consensus protocols or for example MEV or transaction processing. So maybe like kind of at the edges of like, okay, if I show you a proof, maybe you can run this more limited algorithm. Yes, but at the core, it's not really the same tech or the same abstraction. I think all of the entries in that table, ZK, MPC, FHE, TEs, et cetera, crypto economics, they can all chisel away at the centralization. So it's all about using which one is appropriate for your app. Maybe your app is already centralized. Maybe it doesn't need geo-decentralization. Then why would you use a TE, right, et cetera? So I think it's about putting as much as possible off TEs and making TEs also able to be kind of more trusted by having open TEEs and things like that in the future. But yeah, it is a centralization risk for sure. All right, excellent question, excellent answer. How do you think centralization risk of staking compares to the rest of your pillars? I'm not sure what centralization risk of staking means if it means like basically the stake set becoming more centralized or the fact that staking exists centralizing the coin supply I think there's many like slices of staking and centralization I think yes it is kind of implied by the rest of my pillars in my world view like if we have permissionlessness and distribution and specifically geo-decentralization where it's fair for you to participate no matter where you stake, I think you get less stake centralization. So I would say for me it's like downstream of the pillars. If you want to slice it there, I think it is a totally valid thing to have on the table. Say like we don't want centralization into the stake set all right we got one minute more let's try one last question with six upvotes te solve every problem that was previously described in the programmable cryptography session why aren't more people promoting them not only do they solve all the problems but you can use them together to give you defense in depth to give you various optimizations and things like that we're building like a lot of stacks to help people do that. So I think a lot of people are promoting them. I think people are afraid. I think people in crypto and in life and in general, they love binaries. Either TEs are broken and they're useless, they're garbage, we need to burn them down, or they're the best thing ever. And they cast every opinion on TE into one of these two buckets, the reality is much more nuanced. They make sense for a lot of applications. They don't for many others. I think people are promoting and using them and seeing success using them actually basically everywhere they make sense. So I do think you will see more people promoting and using them over time. Definitely in time to come. Ladies and gentlemen, let's give our speaker another big, big round of applause. Thanks, everyone.",
- "eventId": "devcon-7",
- "slot_start": 1731403800000,
- "slot_end": 1731405600000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1bcWYCRlknrhBAHOizptWAGujiHHrSU_sAh9xh-oi1js",
- "resources_slides": null,
- "speakers": [
- "philip-daian"
- ]
- },
- "vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -292085,6 +291543,10 @@
0,
0,
0,
+ 6,
+ 6,
+ 6,
+ 0,
0,
0,
0,
@@ -292146,7 +291608,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -292588,7 +292049,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -292622,6 +292082,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -292632,7 +292093,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -292734,7 +292194,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -292763,6 +292222,19 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -292815,6 +292287,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -293070,12 +292543,14 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -293083,6 +292558,34 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "eth-escape-winner-revealed",
+ "sourceId": "WXS8BH",
+ "title": "ETH Escape Winner Revealed",
+ "description": "We'll announce the winner of ETH Escape.",
+ "track": "[CLS] ETH Escape - Speed Hacking Challenge",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [],
+ "tags": [],
+ "language": "en",
+ "speakers": [
+ "michael-okeeffe"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731576600000,
+ "slot_end": 1731580200000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1lSwPhaKp0iIdGqbNHH0Wq_hG_vGPCW1ja_5qbLVLScg"
+ },
+ "vector": [
0,
0,
0,
@@ -293102,6 +292605,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -293147,7 +292651,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -293156,7 +292659,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -293164,56 +292666,12 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "eth-arauca-emersons-legacy-and-the-hope-for-change-in-vulnerable-communities-through-ethereum",
- "sourceId": "TA3N8E",
- "title": "ETH Arauca: Emerson's Legacy and the Hope for Change in Vulnerable Communities Through Ethereum",
- "description": "In this talk, we will explore the moving case of ETH Arauca and the brave young activist Emerson, who led the ETH Colombia node and whose life was tragically taken in the exercise of his mission. We will analyze how Ethereum, through its vision of decentralized finance, can act as an engine of transformation in vulnerable communities with conflict contexts. This talk seeks to give visibility to Emerson's legacy, ETH leaders challenges, and highlight the potential of Ethereum to drive real change",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Community",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Ethereum",
- "for",
- "Good"
- ],
- "tags": [
- "Decentralization",
- "Local Impact",
- "Social Recovery",
- "ethereum",
- "good",
- "Decentralization",
- "Local Impact",
- "Social Recovery"
- ],
- "language": "en",
- "speakers": [
- "andres-forigua",
- "william-martinez",
- "mateo-sabogal"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731660600000,
- "slot_end": 1731661200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1nM9AZTRUu_izRLyWBvXZg8c-yplG6h0ED_v5As56vgk"
- },
- "vector": [
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -293443,6 +292901,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -293520,9 +292979,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
0,
0,
0,
@@ -294061,7 +293517,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -294127,7 +293582,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -294202,7 +293656,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -294267,7 +293720,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -294445,8 +293897,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -294459,8 +293913,41 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "eth-is-permissionless-money",
+ "sourceId": "TMFPCF",
+ "title": "ETH is permissionless money",
+ "description": "ETH is money! In this talk, we will explore the role of Ethereum's native asset on the base chain, in the L2 ecosystems, and in crypto broadly. We discuss the ETH supply, what it means to be permissionless money, how ETH is being used today, and how it's role can evolve.",
+ "track": "Cryptoeconomics",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Research",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [],
+ "tags": [
+ "Censorship Resistance",
+ "Decentralization",
+ "Ethereum Roadmap"
+ ],
+ "language": "en",
+ "speakers": [
+ "mike-neuder"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731569400000,
+ "slot_end": 1731571200000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1BKehfujLaDakbU2-PjgsWO9PzcaHlv5FlzNG5PlH6zY"
+ },
+ "vector": [
0,
0,
+ 6,
0,
0,
0,
@@ -294522,14 +294009,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -294537,34 +294022,6 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "eth-escape-winner-revealed",
- "sourceId": "WXS8BH",
- "title": "ETH Escape Winner Revealed",
- "description": "We'll announce the winner of ETH Escape.",
- "track": "[CLS] ETH Escape - Speed Hacking Challenge",
- "type": "Music",
- "expertise": "",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "keywords": [],
- "tags": [],
- "language": "en",
- "speakers": [
- "michael-okeeffe"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731576600000,
- "slot_end": 1731580200000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1lSwPhaKp0iIdGqbNHH0Wq_hG_vGPCW1ja_5qbLVLScg"
- },
- "vector": [
0,
0,
0,
@@ -294584,7 +294041,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -294805,6 +294261,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -294881,7 +294338,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -295340,6 +294796,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -295385,6 +294842,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -295428,6 +294886,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -295798,8 +295257,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -295811,12 +295272,55 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "ethereum-a-force-of-good",
+ "sourceId": "HUZP7J",
+ "title": "Ethereum a Force of Good",
+ "description": "Ethereum as a Force for Good\r\nWhat does it mean for Ethereum to be a force of good? How can real-world applications of Ethereum such as RWA, DeFi, and Web3 social right current inequities in the world? What are key blockers that we need to overcome to bring Ethereum into the mainstream? In this talk, Stani will elaborate on how Ethereum is a positive force of change in the world.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Product",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "stablecoins",
+ "supply chain",
+ "agriculture",
+ "scalability"
+ ],
+ "tags": [
+ "RWA",
+ "Ethereum for Good",
+ "Economics",
+ "micropayments",
+ "Economics",
+ "Ethereum for Good",
+ "RWA"
+ ],
+ "language": "en",
+ "speakers": [
+ "stani-kulechov"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731576600000,
+ "slot_end": 1731578400000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1zwoxKxRNSg1zW4w3I3Ad1I6aSDAtCo3sBRkenui4eQ4"
+ },
+ "vector": [
0,
0,
0,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -295879,10 +295383,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -295895,41 +295397,8 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "eth-is-permissionless-money",
- "sourceId": "TMFPCF",
- "title": "ETH is permissionless money",
- "description": "ETH is money! In this talk, we will explore the role of Ethereum's native asset on the base chain, in the L2 ecosystems, and in crypto broadly. We discuss the ETH supply, what it means to be permissionless money, how ETH is being used today, and how it's role can evolve.",
- "track": "Cryptoeconomics",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Research",
- "featured": false,
- "doNotRecord": false,
- "keywords": [],
- "tags": [
- "Censorship Resistance",
- "Decentralization",
- "Ethereum Roadmap"
- ],
- "language": "en",
- "speakers": [
- "mike-neuder"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731569400000,
- "slot_end": 1731571200000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1BKehfujLaDakbU2-PjgsWO9PzcaHlv5FlzNG5PlH6zY"
- },
- "vector": [
0,
0,
- 6,
0,
0,
0,
@@ -296161,6 +295630,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -296244,7 +295714,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -296628,6 +296097,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -296718,6 +296188,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -296745,6 +296216,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -296781,7 +296253,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -296827,7 +296298,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -296871,7 +296341,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -296901,6 +296370,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -297155,11 +296625,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -297168,12 +296640,53 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "ethereum-and-robots",
+ "sourceId": "9G9LSH",
+ "title": "Ethereum and Robots",
+ "description": "I will describe how Ethereum can be used in the emerging consumer robots industry (and generally for autonomous machines).\r\n* privacy preserving surveillance\r\n* autonomous transport\r\n* factory to consumer - tokenization models\r\n* Laws of Robotics - zk hardware",
+ "track": "Real World Ethereum",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Product",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "Robots"
+ ],
+ "tags": [
+ "Collective Intelligence",
+ "Civil Resistance",
+ "DePIN",
+ "Autonomous World",
+ "robots",
+ "Autonomous World",
+ "Civil Resistance",
+ "Collective Intelligence",
+ "DePIN"
+ ],
+ "language": "en",
+ "speakers": [
+ "tomasz-stanczak"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731574800000,
+ "slot_end": 1731576600000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1s1aFTwzOBXNg9v3Cu1EnNW22GUWNxNYFneRubREaJXE"
+ },
+ "vector": [
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -297242,10 +296755,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -297257,54 +296768,12 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "ethereum-a-force-of-good",
- "sourceId": "HUZP7J",
- "title": "Ethereum a Force of Good",
- "description": "Ethereum as a Force for Good\r\nWhat does it mean for Ethereum to be a force of good? How can real-world applications of Ethereum such as RWA, DeFi, and Web3 social right current inequities in the world? What are key blockers that we need to overcome to bring Ethereum into the mainstream? In this talk, Stani will elaborate on how Ethereum is a positive force of change in the world.",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Product",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "stablecoins",
- "supply chain",
- "agriculture",
- "scalability"
- ],
- "tags": [
- "RWA",
- "Ethereum for Good",
- "Economics",
- "micropayments",
- "Economics",
- "Ethereum for Good",
- "RWA"
- ],
- "language": "en",
- "speakers": [
- "stani-kulechov"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731576600000,
- "slot_end": 1731578400000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1zwoxKxRNSg1zW4w3I3Ad1I6aSDAtCo3sBRkenui4eQ4"
- },
- "vector": [
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -297529,6 +296998,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -297616,7 +297086,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -297982,6 +297451,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -297993,6 +297463,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -298068,6 +297539,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -298085,7 +297557,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -298176,7 +297647,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -298188,6 +297658,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -298204,7 +297675,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -298268,6 +297738,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -298359,7 +297830,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -298522,11 +297992,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -298535,11 +298007,51 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "ethereum-citizen-embracing-self-sovereign-digital-identity",
+ "sourceId": "ATKWT8",
+ "title": "Ethereum Citizen: Embracing Self-Sovereign Digital Identity",
+ "description": "The world is changing. Everything is becoming digital. As we seek to extract more from digital services, we are giving them more and more of our personal data.\r\n\r\nBut it doesn't have to be this way. Just as we gained self-sovereignty and ownership over our digital assets and money, we can achieve the same for our digital identities and data using similar and new technologies.\r\n\r\nThis presentation will explain what self-sovereign identity is, why we need it, and where we stand today.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Community",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "Attestations",
+ "data"
+ ],
+ "tags": [
+ "Privacy",
+ "Identity",
+ "Social",
+ "data",
+ "Identity",
+ "Privacy",
+ "Social"
+ ],
+ "language": "en",
+ "speakers": [
+ "vid-kersic"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731646800000,
+ "slot_end": 1731647400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1JzCvRvtEDW6bmL33pf1kIydVAzlZM-tN5p_XZlUg02I"
+ },
+ "vector": [
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -298613,13 +298125,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -298628,59 +298138,6 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "ethereum-and-robots",
- "sourceId": "9G9LSH",
- "title": "Ethereum and Robots",
- "description": "I will describe how Ethereum can be used in the emerging consumer robots industry (and generally for autonomous machines).\r\n* privacy preserving surveillance\r\n* autonomous transport\r\n* factory to consumer - tokenization models\r\n* Laws of Robotics - zk hardware",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Product",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Robots"
- ],
- "tags": [
- "Collective Intelligence",
- "Civil Resistance",
- "DePIN",
- "Autonomous World",
- "robots",
- "Autonomous World",
- "Civil Resistance",
- "Collective Intelligence",
- "DePIN"
- ],
- "language": "en",
- "speakers": [
- "tomasz-stanczak"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731574800000,
- "slot_end": 1731576600000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1s1aFTwzOBXNg9v3Cu1EnNW22GUWNxNYFneRubREaJXE"
- },
- "vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -298908,6 +298365,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -298987,7 +298445,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -299387,6 +298844,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -299442,7 +298900,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -299518,6 +298975,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -299530,9 +298988,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -299730,14 +299185,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -299909,6 +299356,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -299917,6 +299365,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -299924,11 +299373,49 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "ethereum-culture-expanding-in-the-infinite-garden",
+ "sourceId": "ZS338S",
+ "title": "Ethereum Culture Expanding in the Infinite Garden",
+ "description": "As a designer at the EF for the past 5 years, I’ve witnessed the unique culture of Ethereum and its growth. My talk aims to illuminate the vast cultural landscape of our ecosystem such as Cypherpunk, Regen, Degen, and L2s as subculture. I'm hoping to assist ecosystem participants, especially new comers, in becoming the infinite game players in the Infinite Garden.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "Culture",
+ "Subculture",
+ "Infinite Garden"
+ ],
+ "tags": [
+ "Values",
+ "infinite",
+ "garden",
+ "Values"
+ ],
+ "language": "en",
+ "speakers": [
+ "tomo-saito"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731649200000,
+ "slot_end": 1731650400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1A5FoYp0OS56Zm_O5Ba5qVu-PLRcWRf09JijiP2TnAog"
+ },
+ "vector": [
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -299983,13 +299470,12 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 6,
0,
0,
- 2,
0,
0,
0,
@@ -299998,51 +299484,11 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "ethereum-citizen-embracing-self-sovereign-digital-identity",
- "sourceId": "ATKWT8",
- "title": "Ethereum Citizen: Embracing Self-Sovereign Digital Identity",
- "description": "The world is changing. Everything is becoming digital. As we seek to extract more from digital services, we are giving them more and more of our personal data.\r\n\r\nBut it doesn't have to be this way. Just as we gained self-sovereignty and ownership over our digital assets and money, we can achieve the same for our digital identities and data using similar and new technologies.\r\n\r\nThis presentation will explain what self-sovereign identity is, why we need it, and where we stand today.",
- "track": "Cypherpunk & Privacy",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Community",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Attestations",
- "data"
- ],
- "tags": [
- "Privacy",
- "Identity",
- "Social",
- "data",
- "Identity",
- "Privacy",
- "Social"
- ],
- "language": "en",
- "speakers": [
- "vid-kersic"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731646800000,
- "slot_end": 1731647400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1JzCvRvtEDW6bmL33pf1kIydVAzlZM-tN5p_XZlUg02I"
- },
- "vector": [
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -300357,7 +299803,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -300905,7 +300350,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -300969,7 +300413,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -301027,6 +300470,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -301100,7 +300545,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -301278,12 +300722,14 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -301291,10 +300737,54 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "ethereum-execution-layer-specifications-eels",
+ "sourceId": "3GCD7S",
+ "title": "Ethereum Execution Layer Specifications (EELS)",
+ "description": "An introduction and walk-through of the executable specifications for the Ethereum Execution Layer. \r\nGithub (https://github.com/ethereum/execution-specs)\r\n\r\nEELS is an implementation of the EVM in Python that has been optimised for readability. A great tool for EIP authors looking to prototype new ideas on the EVM, it is easy to understand as well as update with new features.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Developer",
+ "featured": false,
+ "doNotRecord": false,
+ "tags": [
+ "Core Protocol",
+ "Layer 1"
+ ],
+ "keywords": [
+ "Execution",
+ "Layer"
+ ],
+ "duration": 1253,
+ "language": "en",
+ "sources_swarmHash": "5152428075c4cdb0ae87fd4ba618e21a8b8d00dee0da4e8f53acff649df95802",
+ "sources_youtubeId": "WEvCFg0Z1D4",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673324473a168eb5355da277.vtt",
+ "transcript_text": " So I'm going to be doing the rest of the talk in English. I'm Guru. I work on the EELS team at the Ethereum Foundation, and I'm really excited to be here and talk to you a little bit about EELS, what we're all about and what we do, where we fit in the larger ecosystem broader picture. So I'll start with what EELS is. EELS stands for the Ethereum Execution Layer Specifications, which means simple enough, we specify the execution layer. But what does it mean to specify the execution layer? There are all these different aspects to the execution layer, different components to it. And what do we mean by specifying the execution layer? We focus solely on basically the core of the execution layer, which is basically the state transition function, the EVM. And when we talk about the state transition function, what I mean is there are a couple of very important questions that we focus on. Let's say I have a blockchain and I'm looking to add a new block to the end of this chain. There are two important questions that EELS tries to answer, answer very precisely. First one is if this new block that I'm trying to add, is it a valid block at all? The second question that we are trying to answer is, let's say it is a valid block, and I add this block to the end of this chain. How does that operation change the state of the chain? So those are the two basic questions that EELS tries to answer, and like I said, tries to answer very precisely. Some of the other aspects of the EL is not something we really look at. We don't look at reorgs, networking, transaction pool, and so on. So those are not focused on when we talk about ELs. And that's our GitHub repository, in case you're interested. I'll give you a QR code at the end of the presentation that you can scan. When we talked about specifying the execution layer, we do this in Python. As you can see on the screenshot on the right, you have a screenshot of the state transition function. There are a few things that you'll already notice in the screenshot. It is executable. It's written in Python, which means you get all of the nice things that you have when you have executable specs. You can kind of isolate components, run components individually, see how they function, try to see the inputs and outputs, all that nice stuff. One of the things that we've done while building EELS is that we have tried to focus heavily on optimizing for readability. That means we want the code to be very readable. We want it to be easy to update. And this is important when I talk a little bit about why we are doing EELS. This readability aspect of EELS is going to be extremely important and has some interesting consequences. And when we also talk about Optimize for Readability, we also mean it's extensively documented. We have taken a lot of effort to document every single component, every single function that's there in EELS, what it does, and kind of speak a little bit more of that. And we have tried to, I mentioned earlier that we have written this in Python, but that is true to the extent, to an extent, but we have not used all the advanced aspects of Python as well. Again, coming back to the readability aspect, because we have tried to keep it as close to pseudocode as possible so that it's not something that's, like, super focused on Python developers. We want everyone to be able to read this. We want everyone to be able to update it. So we have tried to keep the code as close to pseudocode as possible, which is, again, important when we speak about the broader aims that EELS has. Because of these reasons, it's a great playground for prototyping new EIPs. It's something that we have as a focus. We want new EIPs to be prototyped in EELS, and the readability aspect, the ease of updating, the ease of reading, ease of understanding plays a huge role there. The question then is, next question is, why do we need ELs at all? If I were to answer that question, I would like to first look at the EL development cycle that goes on right now. So the execution layer, how new things are added to the execution layer. So typically, when I. So the execution layer, how new things are added to the execution layer. So typically when I talk about the development cycle, these are the two ends of that cycle where on the one hand you have research. Research is basically come up with new ideas that they would like to see in Ethereum, new features that they would like to see. They come up with new EIPs. EIPs are Ethereum improvement proposals. And on the other end of the spectrum is basically the client developers who take these EIPs, update the clients to reflect these changes, and do it in a super optimized way so that it can run in a production level kind of an environment. There it is heavily optimized for performance. Now, with this kind of a framework, there are a few implications that this kind of a framework will have on the EL development cycle. So now let's say you are an EIP author who's proposing a new change. With this kind of a system, there will be a few implications for you. One of the first ones is you will have to update your EIP in one of the clients yourself. Now, like I just mentioned, these clients are production-level softwares. These are not very simple softwares to work with. And there are a lot of moving parts to them. So someone who's not intimately familiar with the software code base might find it a bit of a step to kind of go and implement their EIPs in a production level client. A second implication or a second thing that you can do if you are an EIP author, is you can wait for a client dev to pick this up, pick up your EIP, and implement it in their client. But as I think all of you know, client devs are extremely busy. They have limited bandwidth. Their bandwidth is extremely precious. And so unless the broader community is kind of considering your EIP very seriously, it's unlikely that a client will pick up your EIP and implement it in the clients. A third implication that this kind of a development cycle has is you might end up with different EIPs being added to different clients. For example, recently we had for the Prague, there was discussion around including EOF and 7702 within Prague. And it turned out EOF was implemented on EVM1 and 7702 was first implemented on EthereumJS. So if we are to talk about EIPs and try to kind of find out how EIPs might interact with each other, what are the different side effects, and if they're on multiple different clients, it's a bit of a challenge. You have to wait for it to be implemented all in one place, and then you can kind of answer some of those questions about interactions. So you will have the EIPs scattered in different clients with this kind of architecture. Because maybe I should mention that when I talk about client implementations, we are talking about multiple different clients. So in a post-EELS world, we are looking to move to something slightly different from this. What we are trying to do is this. And a quick shout out to the EAST team. EAST is basically the testing team, and they generate the tests. And I think they have a talk and workshop tomorrow. I would highly recommend you guys check them out, check the talk out tomorrow. But for the purposes of this talk, all you will need to know is EAST is a package that kind of takes a working EVM implementation and spits out tests. It generates tests for you. So that knowledge is enough for the purposes of this talk. So what we are looking for is to move to something like this where the researchers come and implement their EIPs in EELS, which should be extremely easy because it's, like I said earlier, we have optimized for readability and for writing new code, for updating. So this should be very easy, even if the EIP author is unfamiliar with the client code. And EELS is very focused to the state transition function, so there's not a lot of clutter in the EELS code. And then EELS talks to EAST, generates the tests, and the clients, even before they implement their first line of code, have all the tests that they need ready to go. So basically, before they write their first line of code, they have all the tests ready. So there's benefits on both ends of the spectrum. The researchers have an easy way to play around with stuff, iterate on their ideas, and see what are some of the weird edge cases that might come up and so on. And the client does just have to focus on optimizing their implementation. They don't have to worry about tests being there. So EELS and EAST together will take care of that scenario. Okay. Just to summarize some of the advantages of using ELLs. Faster iteration cycle. Researchers playing around with ELLs and, yeah, on the other side, the client is having all the tests ready. With it being a playground, it can throw light on some of the weird edge cases that might come up. So if you were to write a EIP document in Word or in some kind of plain English, it is sometimes going to be a little bit difficult to kind of imagine all the weird edge cases that might come up. Whereas if you're implementing it somewhere, it's more likely that you will encounter something will come up to the surface that you had not considered. It's a one-stop shop for EIP prototyping, which means all the EIPs that we are considering for subsequent updates are in one place. We can answer multiple questions regarding how EIPs interact with each other and what are some of the side effects and those kinds of things. And the last thing is, this also means that the EIP authors get to leverage all the tools that EELS has developed. We have developed a lot of tools to make writing EIP simpler. We have a lot of code analysis tools, linting tools, test filling tools, and these become accessible to the EIP author right out of the box. So it's extremely beneficial. And we are also closely integrated with EAST. EAST is also written in Python, so there's more scope for closer integration when it comes to EELS and EAST. And finally, you have us, the members of the EELS team, who are ready to support you in case you need any help writing the EIPs or in case you need any help regarding EELS. Where are we right now in terms of our roadmap? We have implemented all folks up to and including Prague. So Prague is still not live on mainnet, but we have all the EIPs ready to go. We have implemented them all. We have a working implementation of EOF. A fully functional version of EOF is available, which is, I think, currently being considered for the next fork. It is right now the default test filler for EAST. So if you were to go to EAST and try to fill the tests, EELS would be the EVM implementation that it uses to fill the tests. And finally, the last two points. So we consume all the current tests as well. And the other thing is we have verified all the mainnet blocks using EELS. This is for us to give an additional level of confidence that whatever we have implemented so far, everything until and including Prague is accurate. So we have verified mainnet blocks up until Cancun so far, but we are quickly progressing towards the tip of the chain. And this is where we would like to go in the roadmap that I showed you earlier, why we need EELS. We want to be the first ones to have all the EIP implementations and all the updates to EIP subsequently. So in the post-EELS world, this is one of our main objectives. We would like to develop more tools for EIP authors. Our entire thing is to make development and prototyping of EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP process. There are currently discussions going on around how we kind of enforce this, whether we make it a mandatory part of the EIP process or how. I mean, there are discussions going on on this. This is something we would like to integrate in the EIP process largely. And finally, we would like to also participate in DevNets. When something is being developed and there are DevNets that are live, we would want to be able to have the capacity to verify the chain. Finally, how can you use EELS? Like I mentioned, this is our repository on GitHub, Ethereum Execution Specs. It supports Python 3, 10, and above. I'd like to talk a little bit about our repository structure and the folder structure. So the folks that are live on mainnet are in the master branch, so that is the stable branch. So right now this is everything up until Cancun. And the folks that are under development are in their own branch. This is the nomenclature that we use. Folks Prague is the current development fork, and each EIP within Prague is maintained in its own branch separately. So if you were trying to add a PR, you would create a new EIP branch for your EIP. And this is kind of what the folder structure looks like. The source Ethereum is basically what houses all the specs. And one thing that if you notice, there's a separate folder for each hard fork on the execution layer. For example, Homestead is basically an entire copy of Frontier plus the additional forks that were meant for Homestead and so on. The next fork is basically Homestead plus the next EIPs. Now this is a deliberate choice that we have made. It's not so great from a perspective of code duplication, but it's great when it comes to readability. I've mentioned this a few times already. Readability has been a big focus of ours. So you can just go to one of the folders, for example, Istanbul, and that folder will tell you exactly how the entirety of Istanbul fork works. So there's no clutter with different forks. So you can just go to a particular hard fork and understand entirely how that hard fork works. So this means there are no conditionals. So if you go to a real client, you'll have all these conditionals. If Shanghai do this, if Cancun do this, and so on and so forth, there's no such thing here because of this choice that we have made. There's no clutter in the code, so you can look at each code, each hard fork individually. It's extremely easy to read. But also in a scenario like this, one might legitimately ask the question, how do I track the updates that happen in each fork? So that's an important question. There are a lot of scenarios where you want to answer questions like, oh, what happened in London? What happened in Berlin? And so on. For that, we have a custom diffing tool. And if you look at the screenshot on the right, that's a screenshot of what was the difference between the two hard forks that I've highlighted here, Muir Glacier and Istanbul. So what changed between Istanbul and Muir Glacier? And if you look at the diffing tool, diffing tool is, again, it renders the diffs in HTML on GitHub pages. And if you look at it, it tells you all that happened between Istanbul and Möyreglacier is that we pushed the difficulty bomb. So, yeah. So you can look at the diffs between any consecutive folks this way and have your questions answered. Yeah, this is a team right now. So it's me, Sam, and Peter. Peter's I think in the audience. Sam could not make it to DevCon this year, so shout out to both of them. Finally, how can you contribute? Like any other good open source project, we welcome all kinds of contributions from documentation to any kind of pull requests that you might want to create, any kind of issues that you might want to work on on our repository. But there are two specific ones that I would like to particularly highlight. If you are working on a project that uses an EVM backend, we would love to see if you can integrate EELS into your project and see how easy or difficult that entire process was. We would love to hear from you how that was so that we can kind of improve anything that we have not considered so far. And same with if you're an EIP author, we would love for you to implement your EIP on EELS, and again, we'd love to hear back from you any kind of thing that was difficult or easy, anything that we can improve, any kind of feedback, extremely appreciated. Yeah, that's all I had to say. This QR code takes you to our GitHub repository, and in case there are any questions, I'd be happy to take them. Thank you. Thank you, Guru. So we have one question, and again, the QR code, if you want to get a question in, just throw that up there. But we will start off with this one. How do you write a code that is able to test EL behavior, which would require CL input, like a specific engine API call? Do you also have to implement CL changes? No, we don't implement CL changes. We take, so there's tools that we can, we use the T8n tool for this purpose. And the T8n tool can take the inputs from the CL. For example, I think we are already doing this in Shanghai with withdrawals. So we take the withdrawals as an input. We don't do any kind of checks on them. So that's something that we assume the input that we've gotten is basically what it is, and then try to run the EL block, assuming that as the input that we've gotten is basically what it is and then try to run the EL block assuming that as the input. Thank you. And how do you use slash import block states when validating an existing block? Do you mean I'm trying to understand? We import it as JSON. So if you have all the block parameters in a JSON file, we can import it that way. I'm trying to understand if that's what this question is meant to ask, or if not... If it was your question, quickly put a follow-up. Yeah, I think... That was the question. Oh, okay. That was the question. Okay. Perfect. We got it. Well, thank you, I think. That was the question. Okay, we got it. Well, thank you, thank you. If we have no more questions, we'll wrap it up there. Let's give Guru a huge round of applause. Thank you so much.",
+ "eventId": "devcon-7",
+ "slot_start": 1731402000000,
+ "slot_end": 1731403800000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1tBeUpTPFPiF-99JI_q0F1DV1g8Bx09ZHLkprfgVzn2c",
+ "resources_slides": null,
+ "speakers": [
+ "guruprasad-kamath"
+ ]
+ },
+ "vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -301350,7 +300840,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -301359,57 +300848,14 @@
0,
0,
0,
- 2,
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0
- ]
- },
- {
- "session": {
- "id": "ethereum-culture-expanding-in-the-infinite-garden",
- "sourceId": "ZS338S",
- "title": "Ethereum Culture Expanding in the Infinite Garden",
- "description": "As a designer at the EF for the past 5 years, I’ve witnessed the unique culture of Ethereum and its growth. My talk aims to illuminate the vast cultural landscape of our ecosystem such as Cypherpunk, Regen, Degen, and L2s as subculture. I'm hoping to assist ecosystem participants, especially new comers, in becoming the infinite game players in the Infinite Garden.",
- "track": "Cypherpunk & Privacy",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Community",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Culture",
- "Subculture",
- "Infinite Garden"
- ],
- "tags": [
- "Values",
- "infinite",
- "garden",
- "Values"
- ],
- "language": "en",
- "speakers": [
- "tomo-saito"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731649200000,
- "slot_end": 1731650400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1A5FoYp0OS56Zm_O5Ba5qVu-PLRcWRf09JijiP2TnAog"
- },
- "vector": [
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -301467,7 +300913,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -301655,6 +301100,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -302098,9 +301544,11 @@
0,
0,
0,
+ 6,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -302280,7 +301728,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -302468,8 +301915,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -302645,11 +302090,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -302660,12 +302107,43 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "ethereum-in-30-minutes",
+ "sourceId": "GAJPCN",
+ "title": "Ethereum in 30 minutes",
+ "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
+ "expertise": "",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [],
+ "tags": [],
+ "language": "en",
+ "speakers": [
+ "vitalik-buterin"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731384000000,
+ "slot_end": 1731385800000,
+ "slot_roomId": "main-stage",
+ "sources_youtubeId": "ei3tDRMjw6k",
+ "sources_swarmHash": "d4b974f86276f34632b9a6361a60ff2c85d5da50b1aa85c09829c824eb97c5a9",
+ "resources_presentation": "https://docs.google.com/presentation/d/1c4kXKhLTBksDY0GKRITW1Zog1_t1FjxKAJm7icOjg3I"
+ },
+ "vector": [
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -302719,14 +302197,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -302734,54 +302210,10 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "ethereum-execution-layer-specifications-eels",
- "sourceId": "3GCD7S",
- "title": "Ethereum Execution Layer Specifications (EELS)",
- "description": "An introduction and walk-through of the executable specifications for the Ethereum Execution Layer. \r\nGithub (https://github.com/ethereum/execution-specs)\r\n\r\nEELS is an implementation of the EVM in Python that has been optimised for readability. A great tool for EIP authors looking to prototype new ideas on the EVM, it is easy to understand as well as update with new features.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Developer",
- "featured": false,
- "doNotRecord": false,
- "tags": [
- "Core Protocol",
- "Layer 1"
- ],
- "keywords": [
- "Execution",
- "Layer"
- ],
- "duration": 1253,
- "language": "en",
- "sources_swarmHash": "5152428075c4cdb0ae87fd4ba618e21a8b8d00dee0da4e8f53acff649df95802",
- "sources_youtubeId": "WEvCFg0Z1D4",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673324473a168eb5355da277.vtt",
- "transcript_text": " So I'm going to be doing the rest of the talk in English. I'm Guru. I work on the EELS team at the Ethereum Foundation, and I'm really excited to be here and talk to you a little bit about EELS, what we're all about and what we do, where we fit in the larger ecosystem broader picture. So I'll start with what EELS is. EELS stands for the Ethereum Execution Layer Specifications, which means simple enough, we specify the execution layer. But what does it mean to specify the execution layer? There are all these different aspects to the execution layer, different components to it. And what do we mean by specifying the execution layer? We focus solely on basically the core of the execution layer, which is basically the state transition function, the EVM. And when we talk about the state transition function, what I mean is there are a couple of very important questions that we focus on. Let's say I have a blockchain and I'm looking to add a new block to the end of this chain. There are two important questions that EELS tries to answer, answer very precisely. First one is if this new block that I'm trying to add, is it a valid block at all? The second question that we are trying to answer is, let's say it is a valid block, and I add this block to the end of this chain. How does that operation change the state of the chain? So those are the two basic questions that EELS tries to answer, and like I said, tries to answer very precisely. Some of the other aspects of the EL is not something we really look at. We don't look at reorgs, networking, transaction pool, and so on. So those are not focused on when we talk about ELs. And that's our GitHub repository, in case you're interested. I'll give you a QR code at the end of the presentation that you can scan. When we talked about specifying the execution layer, we do this in Python. As you can see on the screenshot on the right, you have a screenshot of the state transition function. There are a few things that you'll already notice in the screenshot. It is executable. It's written in Python, which means you get all of the nice things that you have when you have executable specs. You can kind of isolate components, run components individually, see how they function, try to see the inputs and outputs, all that nice stuff. One of the things that we've done while building EELS is that we have tried to focus heavily on optimizing for readability. That means we want the code to be very readable. We want it to be easy to update. And this is important when I talk a little bit about why we are doing EELS. This readability aspect of EELS is going to be extremely important and has some interesting consequences. And when we also talk about Optimize for Readability, we also mean it's extensively documented. We have taken a lot of effort to document every single component, every single function that's there in EELS, what it does, and kind of speak a little bit more of that. And we have tried to, I mentioned earlier that we have written this in Python, but that is true to the extent, to an extent, but we have not used all the advanced aspects of Python as well. Again, coming back to the readability aspect, because we have tried to keep it as close to pseudocode as possible so that it's not something that's, like, super focused on Python developers. We want everyone to be able to read this. We want everyone to be able to update it. So we have tried to keep the code as close to pseudocode as possible, which is, again, important when we speak about the broader aims that EELS has. Because of these reasons, it's a great playground for prototyping new EIPs. It's something that we have as a focus. We want new EIPs to be prototyped in EELS, and the readability aspect, the ease of updating, the ease of reading, ease of understanding plays a huge role there. The question then is, next question is, why do we need ELs at all? If I were to answer that question, I would like to first look at the EL development cycle that goes on right now. So the execution layer, how new things are added to the execution layer. So typically, when I. So the execution layer, how new things are added to the execution layer. So typically when I talk about the development cycle, these are the two ends of that cycle where on the one hand you have research. Research is basically come up with new ideas that they would like to see in Ethereum, new features that they would like to see. They come up with new EIPs. EIPs are Ethereum improvement proposals. And on the other end of the spectrum is basically the client developers who take these EIPs, update the clients to reflect these changes, and do it in a super optimized way so that it can run in a production level kind of an environment. There it is heavily optimized for performance. Now, with this kind of a framework, there are a few implications that this kind of a framework will have on the EL development cycle. So now let's say you are an EIP author who's proposing a new change. With this kind of a system, there will be a few implications for you. One of the first ones is you will have to update your EIP in one of the clients yourself. Now, like I just mentioned, these clients are production-level softwares. These are not very simple softwares to work with. And there are a lot of moving parts to them. So someone who's not intimately familiar with the software code base might find it a bit of a step to kind of go and implement their EIPs in a production level client. A second implication or a second thing that you can do if you are an EIP author, is you can wait for a client dev to pick this up, pick up your EIP, and implement it in their client. But as I think all of you know, client devs are extremely busy. They have limited bandwidth. Their bandwidth is extremely precious. And so unless the broader community is kind of considering your EIP very seriously, it's unlikely that a client will pick up your EIP and implement it in the clients. A third implication that this kind of a development cycle has is you might end up with different EIPs being added to different clients. For example, recently we had for the Prague, there was discussion around including EOF and 7702 within Prague. And it turned out EOF was implemented on EVM1 and 7702 was first implemented on EthereumJS. So if we are to talk about EIPs and try to kind of find out how EIPs might interact with each other, what are the different side effects, and if they're on multiple different clients, it's a bit of a challenge. You have to wait for it to be implemented all in one place, and then you can kind of answer some of those questions about interactions. So you will have the EIPs scattered in different clients with this kind of architecture. Because maybe I should mention that when I talk about client implementations, we are talking about multiple different clients. So in a post-EELS world, we are looking to move to something slightly different from this. What we are trying to do is this. And a quick shout out to the EAST team. EAST is basically the testing team, and they generate the tests. And I think they have a talk and workshop tomorrow. I would highly recommend you guys check them out, check the talk out tomorrow. But for the purposes of this talk, all you will need to know is EAST is a package that kind of takes a working EVM implementation and spits out tests. It generates tests for you. So that knowledge is enough for the purposes of this talk. So what we are looking for is to move to something like this where the researchers come and implement their EIPs in EELS, which should be extremely easy because it's, like I said earlier, we have optimized for readability and for writing new code, for updating. So this should be very easy, even if the EIP author is unfamiliar with the client code. And EELS is very focused to the state transition function, so there's not a lot of clutter in the EELS code. And then EELS talks to EAST, generates the tests, and the clients, even before they implement their first line of code, have all the tests that they need ready to go. So basically, before they write their first line of code, they have all the tests ready. So there's benefits on both ends of the spectrum. The researchers have an easy way to play around with stuff, iterate on their ideas, and see what are some of the weird edge cases that might come up and so on. And the client does just have to focus on optimizing their implementation. They don't have to worry about tests being there. So EELS and EAST together will take care of that scenario. Okay. Just to summarize some of the advantages of using ELLs. Faster iteration cycle. Researchers playing around with ELLs and, yeah, on the other side, the client is having all the tests ready. With it being a playground, it can throw light on some of the weird edge cases that might come up. So if you were to write a EIP document in Word or in some kind of plain English, it is sometimes going to be a little bit difficult to kind of imagine all the weird edge cases that might come up. Whereas if you're implementing it somewhere, it's more likely that you will encounter something will come up to the surface that you had not considered. It's a one-stop shop for EIP prototyping, which means all the EIPs that we are considering for subsequent updates are in one place. We can answer multiple questions regarding how EIPs interact with each other and what are some of the side effects and those kinds of things. And the last thing is, this also means that the EIP authors get to leverage all the tools that EELS has developed. We have developed a lot of tools to make writing EIP simpler. We have a lot of code analysis tools, linting tools, test filling tools, and these become accessible to the EIP author right out of the box. So it's extremely beneficial. And we are also closely integrated with EAST. EAST is also written in Python, so there's more scope for closer integration when it comes to EELS and EAST. And finally, you have us, the members of the EELS team, who are ready to support you in case you need any help writing the EIPs or in case you need any help regarding EELS. Where are we right now in terms of our roadmap? We have implemented all folks up to and including Prague. So Prague is still not live on mainnet, but we have all the EIPs ready to go. We have implemented them all. We have a working implementation of EOF. A fully functional version of EOF is available, which is, I think, currently being considered for the next fork. It is right now the default test filler for EAST. So if you were to go to EAST and try to fill the tests, EELS would be the EVM implementation that it uses to fill the tests. And finally, the last two points. So we consume all the current tests as well. And the other thing is we have verified all the mainnet blocks using EELS. This is for us to give an additional level of confidence that whatever we have implemented so far, everything until and including Prague is accurate. So we have verified mainnet blocks up until Cancun so far, but we are quickly progressing towards the tip of the chain. And this is where we would like to go in the roadmap that I showed you earlier, why we need EELS. We want to be the first ones to have all the EIP implementations and all the updates to EIP subsequently. So in the post-EELS world, this is one of our main objectives. We would like to develop more tools for EIP authors. Our entire thing is to make development and prototyping of EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP simpler. So we would like to build more tooling for EIP authors. We would also want to integrate into the EIP process. There are currently discussions going on around how we kind of enforce this, whether we make it a mandatory part of the EIP process or how. I mean, there are discussions going on on this. This is something we would like to integrate in the EIP process largely. And finally, we would like to also participate in DevNets. When something is being developed and there are DevNets that are live, we would want to be able to have the capacity to verify the chain. Finally, how can you use EELS? Like I mentioned, this is our repository on GitHub, Ethereum Execution Specs. It supports Python 3, 10, and above. I'd like to talk a little bit about our repository structure and the folder structure. So the folks that are live on mainnet are in the master branch, so that is the stable branch. So right now this is everything up until Cancun. And the folks that are under development are in their own branch. This is the nomenclature that we use. Folks Prague is the current development fork, and each EIP within Prague is maintained in its own branch separately. So if you were trying to add a PR, you would create a new EIP branch for your EIP. And this is kind of what the folder structure looks like. The source Ethereum is basically what houses all the specs. And one thing that if you notice, there's a separate folder for each hard fork on the execution layer. For example, Homestead is basically an entire copy of Frontier plus the additional forks that were meant for Homestead and so on. The next fork is basically Homestead plus the next EIPs. Now this is a deliberate choice that we have made. It's not so great from a perspective of code duplication, but it's great when it comes to readability. I've mentioned this a few times already. Readability has been a big focus of ours. So you can just go to one of the folders, for example, Istanbul, and that folder will tell you exactly how the entirety of Istanbul fork works. So there's no clutter with different forks. So you can just go to a particular hard fork and understand entirely how that hard fork works. So this means there are no conditionals. So if you go to a real client, you'll have all these conditionals. If Shanghai do this, if Cancun do this, and so on and so forth, there's no such thing here because of this choice that we have made. There's no clutter in the code, so you can look at each code, each hard fork individually. It's extremely easy to read. But also in a scenario like this, one might legitimately ask the question, how do I track the updates that happen in each fork? So that's an important question. There are a lot of scenarios where you want to answer questions like, oh, what happened in London? What happened in Berlin? And so on. For that, we have a custom diffing tool. And if you look at the screenshot on the right, that's a screenshot of what was the difference between the two hard forks that I've highlighted here, Muir Glacier and Istanbul. So what changed between Istanbul and Muir Glacier? And if you look at the diffing tool, diffing tool is, again, it renders the diffs in HTML on GitHub pages. And if you look at it, it tells you all that happened between Istanbul and Möyreglacier is that we pushed the difficulty bomb. So, yeah. So you can look at the diffs between any consecutive folks this way and have your questions answered. Yeah, this is a team right now. So it's me, Sam, and Peter. Peter's I think in the audience. Sam could not make it to DevCon this year, so shout out to both of them. Finally, how can you contribute? Like any other good open source project, we welcome all kinds of contributions from documentation to any kind of pull requests that you might want to create, any kind of issues that you might want to work on on our repository. But there are two specific ones that I would like to particularly highlight. If you are working on a project that uses an EVM backend, we would love to see if you can integrate EELS into your project and see how easy or difficult that entire process was. We would love to hear from you how that was so that we can kind of improve anything that we have not considered so far. And same with if you're an EIP author, we would love for you to implement your EIP on EELS, and again, we'd love to hear back from you any kind of thing that was difficult or easy, anything that we can improve, any kind of feedback, extremely appreciated. Yeah, that's all I had to say. This QR code takes you to our GitHub repository, and in case there are any questions, I'd be happy to take them. Thank you. Thank you, Guru. So we have one question, and again, the QR code, if you want to get a question in, just throw that up there. But we will start off with this one. How do you write a code that is able to test EL behavior, which would require CL input, like a specific engine API call? Do you also have to implement CL changes? No, we don't implement CL changes. We take, so there's tools that we can, we use the T8n tool for this purpose. And the T8n tool can take the inputs from the CL. For example, I think we are already doing this in Shanghai with withdrawals. So we take the withdrawals as an input. We don't do any kind of checks on them. So that's something that we assume the input that we've gotten is basically what it is, and then try to run the EL block, assuming that as the input that we've gotten is basically what it is and then try to run the EL block assuming that as the input. Thank you. And how do you use slash import block states when validating an existing block? Do you mean I'm trying to understand? We import it as JSON. So if you have all the block parameters in a JSON file, we can import it that way. I'm trying to understand if that's what this question is meant to ask, or if not... If it was your question, quickly put a follow-up. Yeah, I think... That was the question. Oh, okay. That was the question. Okay. Perfect. We got it. Well, thank you, I think. That was the question. Okay, we got it. Well, thank you, thank you. If we have no more questions, we'll wrap it up there. Let's give Guru a huge round of applause. Thank you so much.",
- "eventId": "devcon-7",
- "slot_start": 1731402000000,
- "slot_end": 1731403800000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1tBeUpTPFPiF-99JI_q0F1DV1g8Bx09ZHLkprfgVzn2c",
- "resources_slides": null,
- "speakers": [
- "guruprasad-kamath"
- ]
- },
- "vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -302894,6 +302326,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -303098,7 +302531,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -303544,11 +302976,9 @@
0,
0,
0,
- 6,
0,
0,
0,
- 2,
0,
0,
0,
@@ -304018,8 +303448,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -304032,12 +303464,48 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "ethereum-in-the-classroom-or-teaching-solidity-to-high-school-students-in-buenos-aires",
+ "sourceId": "9HFAES",
+ "title": "Ethereum in the Classroom | Teaching Solidity to High School Students in Buenos Aires",
+ "description": "ETH Kipu is breaking new ground by introducing Ethereum education to teenagers in Argentina. Discover how we collaborated with the Buenos Aires Ministry of Education to create hands-on learning experiences, teaching students to build smart contracts using Solidity. This talk will share best practices from our experience and how it can be replicated globally, sharing the insights we have discovered in the classroom and how we develop this partnership.",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Academic",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "Education"
+ ],
+ "tags": [
+ "Design Thinking",
+ "Ethereum for Good",
+ "Public good"
+ ],
+ "language": "en",
+ "speakers": [
+ "romina-sejas",
+ "juan-david-reyes"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731559200000,
+ "slot_end": 1731559800000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1clRG027QMaA-_D-yds9TfGuZXmzRy5tpHKs67z97Mqw"
+ },
+ "vector": [
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -304090,13 +303558,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -304107,43 +303573,12 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "ethereum-in-30-minutes",
- "sourceId": "GAJPCN",
- "title": "Ethereum in 30 minutes",
- "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "keywords": [],
- "tags": [],
- "language": "en",
- "speakers": [
- "vitalik-buterin"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731384000000,
- "slot_end": 1731385800000,
- "slot_roomId": "main-stage",
- "sources_youtubeId": "ei3tDRMjw6k",
- "sources_swarmHash": "d4b974f86276f34632b9a6361a60ff2c85d5da50b1aa85c09829c824eb97c5a9",
- "resources_presentation": "https://docs.google.com/presentation/d/1c4kXKhLTBksDY0GKRITW1Zog1_t1FjxKAJm7icOjg3I"
- },
- "vector": [
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -304327,86 +303762,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -304465,6 +303820,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -305000,6 +304357,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -305016,6 +304374,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -305033,6 +304392,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -305454,8 +304814,6 @@
2,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -305464,6 +304822,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -305472,34 +304831,33 @@
},
{
"session": {
- "id": "ethereum-in-the-classroom-or-teaching-solidity-to-high-school-students-in-buenos-aires",
- "sourceId": "9HFAES",
- "title": "Ethereum in the Classroom | Teaching Solidity to High School Students in Buenos Aires",
- "description": "ETH Kipu is breaking new ground by introducing Ethereum education to teenagers in Argentina. Discover how we collaborated with the Buenos Aires Ministry of Education to create hands-on learning experiences, teaching students to build smart contracts using Solidity. This talk will share best practices from our experience and how it can be replicated globally, sharing the insights we have discovered in the classroom and how we develop this partnership.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Academic",
+ "id": "ethereum-needs-native-l2",
+ "sourceId": "9RNWDX",
+ "title": "Ethereum needs native L2",
+ "description": "Right now, L2beat tracks 116 L2s. However, they represent a wide range of trust assumptions, which makes assets—or more abstractly, messages—from these L2s non-fungible and thus significantly hampers interoperability. We are advocating for Ethereum to deploy a large number of native L2s, developed and governed by Ethereum's open-source developers. These L2s would be highly interoperable with L1, fulfilling Ethereum's early promise to provide sharding using L2 technology.",
+ "track": "Layer 2",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Education"
+ "interoperability"
],
"tags": [
- "Design Thinking",
- "Ethereum for Good",
- "Public good"
+ "Cross-L2",
+ "Ethereum Roadmap",
+ "Scalability"
],
"language": "en",
"speakers": [
- "romina-sejas",
- "juan-david-reyes"
+ "koeppelmann"
],
"eventId": "devcon-7",
- "slot_start": 1731559200000,
- "slot_end": 1731559800000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1clRG027QMaA-_D-yds9TfGuZXmzRy5tpHKs67z97Mqw"
+ "slot_start": 1731643200000,
+ "slot_end": 1731645000000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1kNj2hbZYPECNuJmWk7WXk0CzL745n9QV5DwtBh6rF6A"
},
"vector": [
0,
@@ -305508,9 +304866,8 @@
0,
0,
0,
- 6,
- 0,
0,
+ 6,
0,
0,
0,
@@ -305677,6 +305034,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -305824,8 +305182,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -306363,7 +305719,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -306380,7 +305735,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -306395,10 +305749,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -306447,6 +305801,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -306454,6 +305809,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -306814,6 +306170,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -306828,8 +306185,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0
@@ -306837,33 +306192,39 @@
},
{
"session": {
- "id": "ethereum-needs-native-l2",
- "sourceId": "9RNWDX",
- "title": "Ethereum needs native L2",
- "description": "Right now, L2beat tracks 116 L2s. However, they represent a wide range of trust assumptions, which makes assets—or more abstractly, messages—from these L2s non-fungible and thus significantly hampers interoperability. We are advocating for Ethereum to deploy a large number of native L2s, developed and governed by Ethereum's open-source developers. These L2s would be highly interoperable with L1, fulfilling Ethereum's early promise to provide sharding using L2 technology.",
- "track": "Layer 2",
+ "id": "ethereum-privacy-ecosystem-overview",
+ "sourceId": "GDSWLR",
+ "title": "Ethereum Privacy Ecosystem overview",
+ "description": "I want to present the Ethereum Privacy Ecosystem report that Web3Privacy now collective is doing:\r\n\r\n- highlighting the state of Privacy in Ethereum (helicopter/ecosystem viewpoint)\r\n- presenting a structural map of privacy-focused projects, EIPs & R&Ds, hackathon projects, and funding mechanisms\r\n- backed by the data: X projects from Railgun to Firn, Y hackathons from ETHBerlin to ETHRome, Z funding from Gitcoin (example: Rotki) to VC (Aztec)\r\n- sharing public & open research links",
+ "track": "Cypherpunk & Privacy",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "interoperability"
+ "hackathons",
+ "funding",
+ ""
],
"tags": [
- "Cross-L2",
- "Ethereum Roadmap",
- "Scalability"
+ "Privacy",
+ "Censorship Resistance",
+ "Use Cases",
+ "funding",
+ "Censorship Resistance",
+ "Privacy",
+ "Use Cases"
],
"language": "en",
"speakers": [
- "koeppelmann"
+ "mykola-siusko"
],
"eventId": "devcon-7",
- "slot_start": 1731643200000,
- "slot_end": 1731645000000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1kNj2hbZYPECNuJmWk7WXk0CzL745n9QV5DwtBh6rF6A"
+ "slot_start": 1731396600000,
+ "slot_end": 1731398400000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1DcPpiyOXnniGj_ZNc1gb9EibNmlffDlWC8bwLQ3ky-Q"
},
"vector": [
0,
@@ -306871,8 +306232,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -307041,7 +306400,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -307192,6 +306550,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -307696,6 +307055,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -307732,6 +307092,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -307758,12 +307119,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -307810,7 +307171,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -307818,7 +307178,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -307930,6 +307289,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -308183,12 +307543,10 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -308201,39 +307559,42 @@
},
{
"session": {
- "id": "ethereum-privacy-ecosystem-overview",
- "sourceId": "GDSWLR",
- "title": "Ethereum Privacy Ecosystem overview",
- "description": "I want to present the Ethereum Privacy Ecosystem report that Web3Privacy now collective is doing:\r\n\r\n- highlighting the state of Privacy in Ethereum (helicopter/ecosystem viewpoint)\r\n- presenting a structural map of privacy-focused projects, EIPs & R&Ds, hackathon projects, and funding mechanisms\r\n- backed by the data: X projects from Railgun to Firn, Y hackathons from ETHBerlin to ETHRome, Z funding from Gitcoin (example: Rotki) to VC (Aztec)\r\n- sharing public & open research links",
- "track": "Cypherpunk & Privacy",
- "type": "Talk",
+ "id": "ethereum-real-world-economy",
+ "sourceId": "JSYMFD",
+ "title": "Ethereum Real World Economy",
+ "description": "Ethereum’s role as universal settlement layer is growing fast. Tradfi companies like Stripe are building on-chain, while native projects like Polymarket are increasingly impactful in the real world.\r\n\r\nThis panel will debate the future of “Real-World Ethereum”. What does that mean? How do we maximize growth opportunities while avoiding capture? What can we learn from history? How do we best compete, and how do we ensure Ethereum values as we power more and more of the world outside crypto?",
+ "track": "Real World Ethereum",
+ "type": "Panel",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "hackathons",
- "funding",
- ""
+ "stablecoins",
+ "real-world-use",
+ "use-cases"
],
"tags": [
- "Privacy",
- "Censorship Resistance",
+ "Ethereum Roadmap",
"Use Cases",
- "funding",
- "Censorship Resistance",
- "Privacy",
+ "e/acc",
+ "case",
+ "use",
+ "e/acc",
+ "Ethereum Roadmap",
"Use Cases"
],
"language": "en",
"speakers": [
- "mykola-siusko"
+ "tim-beiko",
+ "dc-posch",
+ "liam-horne"
],
"eventId": "devcon-7",
- "slot_start": 1731396600000,
- "slot_end": 1731398400000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1DcPpiyOXnniGj_ZNc1gb9EibNmlffDlWC8bwLQ3ky-Q"
+ "slot_start": 1731571200000,
+ "slot_end": 1731574800000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1UVP1zLQ1cszDLmjMKl61KN2rP616jJTze1YhwSPWhms"
},
"vector": [
0,
@@ -308241,6 +307602,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -308379,6 +307741,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -308419,6 +307782,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -308557,10 +307921,10 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -309061,13 +308425,16 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -309104,7 +308471,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -309172,6 +308538,16 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -309277,32 +308653,14 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
0,
0,
0,
@@ -309553,12 +308911,12 @@
0,
2,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -309571,42 +308929,31 @@
},
{
"session": {
- "id": "ethereum-real-world-economy",
- "sourceId": "JSYMFD",
- "title": "Ethereum Real World Economy",
- "description": "Ethereum’s role as universal settlement layer is growing fast. Tradfi companies like Stripe are building on-chain, while native projects like Polymarket are increasingly impactful in the real world.\r\n\r\nThis panel will debate the future of “Real-World Ethereum”. What does that mean? How do we maximize growth opportunities while avoiding capture? What can we learn from history? How do we best compete, and how do we ensure Ethereum values as we power more and more of the world outside crypto?",
+ "id": "ethereums-ultimate-gift-will-be-birthing-digital-matter",
+ "sourceId": "XSCFZR",
+ "title": "Ethereum's Ultimate Gift Will Be Birthing Digital Matter",
+ "description": "Bitcoin created Digital Gold, intangible yet valued like real gold. Ethereum will birth Digital Worlds which culture will treat as real. Unlike Bitcoin's scarce digital coins and tamper-proof IOUs, these worlds will have scarce digital matter and tamper-proof physics. Within them, inhabitants will use primitives like smart items to build economies and civilizations with society-shifting GDPs.",
"track": "Real World Ethereum",
- "type": "Panel",
+ "type": "Talk",
"expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "stablecoins",
- "real-world-use",
- "use-cases"
- ],
+ "keywords": [],
"tags": [
- "Ethereum Roadmap",
- "Use Cases",
- "e/acc",
- "case",
- "use",
- "e/acc",
- "Ethereum Roadmap",
+ "Autonomous World",
+ "Gaming",
"Use Cases"
],
"language": "en",
"speakers": [
- "tim-beiko",
- "dc-posch",
- "liam-horne"
+ "dhrumil-shah"
],
"eventId": "devcon-7",
- "slot_start": 1731571200000,
- "slot_end": 1731574800000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1UVP1zLQ1cszDLmjMKl61KN2rP616jJTze1YhwSPWhms"
+ "slot_start": 1731494400000,
+ "slot_end": 1731496200000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/15oxvM3TxOCUK4NDmYqvX1h3RKEylrnyt66ZdyLe_RR0"
},
"vector": [
0,
@@ -309685,6 +309032,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -309754,8 +309102,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -309795,7 +309141,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -309934,7 +309279,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -310471,6 +309815,9 @@
0,
0,
0,
+ 2,
+ 2,
+ 0,
0,
0,
0,
@@ -310517,7 +309864,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -310553,7 +309899,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -310676,7 +310021,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -310944,31 +310288,43 @@
},
{
"session": {
- "id": "ethereums-ultimate-gift-will-be-birthing-digital-matter",
- "sourceId": "XSCFZR",
- "title": "Ethereum's Ultimate Gift Will Be Birthing Digital Matter",
- "description": "Bitcoin created Digital Gold, intangible yet valued like real gold. Ethereum will birth Digital Worlds which culture will treat as real. Unlike Bitcoin's scarce digital coins and tamper-proof IOUs, these worlds will have scarce digital matter and tamper-proof physics. Within them, inhabitants will use primitives like smart items to build economies and civilizations with society-shifting GDPs.",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "id": "ethereums-values-and-ethos-alignment-pre-merge-to-now",
+ "sourceId": "UHAESN",
+ "title": "Ethereum's Values and Ethos Alignment: Pre-Merge to Now",
+ "description": "If you ask Ethereans to describe \"What is Ethereum?\" in 1 sentence, what would it be? Likely, you will get many different answers depending on who you're speaking to. Some visions have changed over time and some stayed true to the cypherpunk values such as decentralization, trustlessness & censorship-resistance. Or is it more important for us to focus on DA & scalability at L1? What should L1 actually be responsible for? Is local block building dead? Are timing games bad? What do we value today?",
+ "track": "Cypherpunk & Privacy",
+ "type": "Panel",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [],
+ "keywords": [
+ "ethos",
+ "values",
+ "alignment"
+ ],
"tags": [
- "Autonomous World",
- "Gaming",
- "Use Cases"
+ "Layer 1",
+ "Ethereum Roadmap",
+ "Coordination",
+ "alignment",
+ "Coordination",
+ "Ethereum Roadmap",
+ "Layer 1"
],
"language": "en",
"speakers": [
- "dhrumil-shah"
+ "peter-szilagyi",
+ "ahmad-bitar",
+ "phil-ngo",
+ "nixo",
+ "mark-tyneway"
],
"eventId": "devcon-7",
- "slot_start": 1731494400000,
- "slot_end": 1731496200000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/15oxvM3TxOCUK4NDmYqvX1h3RKEylrnyt66ZdyLe_RR0"
+ "slot_start": 1731564000000,
+ "slot_end": 1731567600000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1pDeSitEvmVhEFya_w3q8q2Uq4_YVvfaQsg5BA5nTUaI"
},
"vector": [
0,
@@ -310976,7 +310332,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -311047,9 +310402,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -311142,6 +310494,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -311232,6 +310585,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -311298,6 +310652,9 @@
0,
0,
0,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -311734,6 +311091,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -311802,7 +311160,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -311833,8 +311190,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -311876,6 +311231,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -311912,6 +311268,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -312034,6 +311391,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -312279,6 +311637,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -312286,7 +311645,6 @@
0,
0,
0,
- 2,
0,
2,
0,
@@ -312296,61 +311654,52 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "ethereums-values-and-ethos-alignment-pre-merge-to-now",
- "sourceId": "UHAESN",
- "title": "Ethereum's Values and Ethos Alignment: Pre-Merge to Now",
- "description": "If you ask Ethereans to describe \"What is Ethereum?\" in 1 sentence, what would it be? Likely, you will get many different answers depending on who you're speaking to. Some visions have changed over time and some stayed true to the cypherpunk values such as decentralization, trustlessness & censorship-resistance. Or is it more important for us to focus on DA & scalability at L1? What should L1 actually be responsible for? Is local block building dead? Are timing games bad? What do we value today?",
- "track": "Cypherpunk & Privacy",
- "type": "Panel",
+ "id": "ethersjs-api-hidden-gems",
+ "sourceId": "EG8ML8",
+ "title": "Ethers.js - API Hidden Gems",
+ "description": "There are many shortcuts and powerful API features in Ethers.js which go unnoticed or under-exploited. The goal of this talk is to raise awareness, provide examples and encourage usage of some of these useful APIs to unlock features which can improve user experience, user security and be more transparent to users.",
+ "track": "Developer Experience",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "ethos",
- "values",
- "alignment"
+ "Ethers",
+ "API"
],
"tags": [
- "Layer 1",
- "Ethereum Roadmap",
- "Coordination",
- "alignment",
- "Coordination",
- "Ethereum Roadmap",
- "Layer 1"
+ "DevEx",
+ "Testing",
+ "UI/UX",
+ "api",
+ "DevEx",
+ "Testing",
+ "UI/UX"
],
"language": "en",
"speakers": [
- "peter-szilagyi",
- "ahmad-bitar",
- "phil-ngo",
- "nixo",
- "mark-tyneway"
+ "richard-moore"
],
"eventId": "devcon-7",
- "slot_start": 1731564000000,
- "slot_end": 1731567600000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1pDeSitEvmVhEFya_w3q8q2Uq4_YVvfaQsg5BA5nTUaI"
+ "slot_start": 1731646800000,
+ "slot_end": 1731648600000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1B_Zxh9JTKekXGn74kLQf28CCReGTzSYFG5ED2_8egac"
},
"vector": [
0,
0,
0,
+ 6,
+ 0,
0,
0,
- 6,
0,
0,
0,
@@ -312513,7 +311862,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -312603,7 +311951,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -312671,12 +312018,10 @@
0,
0,
0,
- 6,
- 6,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -313112,7 +312457,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -313128,6 +312472,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -313156,6 +312501,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -313252,7 +312598,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -313289,7 +312634,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -313338,6 +312682,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -313664,10 +313009,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -313680,42 +313025,33 @@
},
{
"session": {
- "id": "ethersjs-api-hidden-gems",
- "sourceId": "EG8ML8",
- "title": "Ethers.js - API Hidden Gems",
- "description": "There are many shortcuts and powerful API features in Ethers.js which go unnoticed or under-exploited. The goal of this talk is to raise awareness, provide examples and encourage usage of some of these useful APIs to unlock features which can improve user experience, user security and be more transparent to users.",
- "track": "Developer Experience",
- "type": "Talk",
+ "id": "ethos-dgen1-self-sovereign-os-hardware",
+ "sourceId": "TALWUM",
+ "title": "ethOS + dGEN1: Self sovereign OS + Hardware",
+ "description": "In this talk I will talk about ethOS, the dGEN1 and the concept of self sovereign software and hardware.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Ethers",
- "API"
- ],
+ "keywords": [],
"tags": [
- "DevEx",
- "Testing",
- "UI/UX",
- "api",
- "DevEx",
- "Testing",
+ "DePIN",
+ "Mobile",
"UI/UX"
],
"language": "en",
"speakers": [
- "richard-moore"
+ "markus-haas"
],
"eventId": "devcon-7",
- "slot_start": 1731646800000,
- "slot_end": 1731648600000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1B_Zxh9JTKekXGn74kLQf28CCReGTzSYFG5ED2_8egac"
+ "slot_start": 1731577500000,
+ "slot_end": 1731578400000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1_547FFGifntr2F9NLRt6mgJnjr6QzNRpm-JcA8hqP_c"
},
"vector": [
- 0,
- 0,
0,
6,
0,
@@ -314043,9 +313379,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -314487,6 +313823,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -314496,7 +313834,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -314523,9 +313860,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -314707,7 +314044,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -314783,7 +314119,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -315031,9 +314366,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -315049,41 +314384,48 @@
},
{
"session": {
- "id": "ethos-dgen1-self-sovereign-os-hardware",
- "sourceId": "TALWUM",
- "title": "ethOS + dGEN1: Self sovereign OS + Hardware",
- "description": "In this talk I will talk about ethOS, the dGEN1 and the concept of self sovereign software and hardware.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
+ "id": "eve-frontier-challenges-lessons-and-future-of-building-an-autonomous-world-on-ethereum",
+ "sourceId": "QLK8UE",
+ "title": "EVE Frontier - challenges, lessons and future of building an autonomous world on Ethereum",
+ "description": "CCP Games—the creators of the legendary space-based MMO EVE Online, home to millions of space merchants, pirates, and explorers—is building a new world, and it is going to live onchain and run on the EVM.\r\n\r\nHear from the CCP team as they discuss challenges, learnings, and open questions of building massive virtual worlds onchain—what to put onchain first? What game mechanics are best suited onchain? What are the unlocks?—as well as what EVE Frontier might bring to the Ethereum ecosystem.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
+ "expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
+ "keywords": [
+ "MUD",
+ "EVE Frontier",
+ "EVE Online"
+ ],
"tags": [
- "DePIN",
- "Mobile",
- "UI/UX"
+ "Gaming",
+ "Autonomous World",
+ "eve",
+ "online",
+ "Autonomous World",
+ "Gaming"
],
"language": "en",
"speakers": [
- "markus-haas"
+ "justin-glibert",
+ "hilmar-petursson"
],
"eventId": "devcon-7",
- "slot_start": 1731577500000,
- "slot_end": 1731578400000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1_547FFGifntr2F9NLRt6mgJnjr6QzNRpm-JcA8hqP_c"
+ "slot_start": 1731468600000,
+ "slot_end": 1731470400000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1mqLIgd8le45XgG2FPsR3vi1IafiikIiEzC9TaHmFCvk"
},
"vector": [
- 0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -315258,6 +314600,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -315850,10 +315193,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -315887,7 +315226,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -315940,6 +315278,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -316145,6 +315485,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -316391,8 +315733,6 @@
0,
2,
0,
- 0,
- 0,
2,
0,
0,
@@ -316411,39 +315751,33 @@
},
{
"session": {
- "id": "eve-frontier-challenges-lessons-and-future-of-building-an-autonomous-world-on-ethereum",
- "sourceId": "QLK8UE",
- "title": "EVE Frontier - challenges, lessons and future of building an autonomous world on Ethereum",
- "description": "CCP Games—the creators of the legendary space-based MMO EVE Online, home to millions of space merchants, pirates, and explorers—is building a new world, and it is going to live onchain and run on the EVM.\r\n\r\nHear from the CCP team as they discuss challenges, learnings, and open questions of building massive virtual worlds onchain—what to put onchain first? What game mechanics are best suited onchain? What are the unlocks?—as well as what EVE Frontier might bring to the Ethereum ecosystem.",
- "track": "Real World Ethereum",
- "type": "Talk",
+ "id": "eve-frontier-mud-day-demo",
+ "sourceId": "RMKJTL",
+ "title": "EVE Frontier - MUD Day Demo",
+ "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nEVE Frontier, is a single-shard survival game from CCP Games—the creators of the legendary space-based MMO EVE Online.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Engineering",
+ "audience": "Product",
"featured": false,
- "doNotRecord": false,
- "keywords": [
- "MUD",
- "EVE Frontier",
- "EVE Online"
- ],
+ "doNotRecord": true,
+ "keywords": [],
"tags": [
"Gaming",
"Autonomous World",
- "eve",
- "online",
"Autonomous World",
"Gaming"
],
"language": "en",
"speakers": [
- "justin-glibert",
- "hilmar-petursson"
+ "toniya-sundaram",
+ "scott-mccabe"
],
"eventId": "devcon-7",
- "slot_start": 1731468600000,
- "slot_end": 1731470400000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1mqLIgd8le45XgG2FPsR3vi1IafiikIiEzC9TaHmFCvk"
+ "slot_start": 1731556500000,
+ "slot_end": 1731556800000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1uN2SOUzGZIHw0d3Pw3RkvvmxeEi6RqnN2J0-JbWUMHI"
},
"vector": [
0,
@@ -316452,16 +315786,13 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -316599,6 +315930,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -316628,7 +315961,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -316777,7 +316109,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -317516,8 +316847,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -317761,7 +317090,7 @@
0,
0,
0,
- 2,
+ 0,
0,
2,
0,
@@ -317769,6 +317098,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -317781,39 +317112,55 @@
},
{
"session": {
- "id": "eve-frontier-mud-day-demo",
- "sourceId": "RMKJTL",
- "title": "EVE Frontier - MUD Day Demo",
- "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nEVE Frontier, is a single-shard survival game from CCP Games—the creators of the legendary space-based MMO EVE Online.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "id": "everything-you-need-to-know-about-state-expiry",
+ "sourceId": "MZXQKJ",
+ "title": "Everything you need to know about state expiry",
+ "description": "State growth is a ticking time bomb for Ethereum, yet concrete solutions remain elusive. While statelessness offers promise, it doesn't address the root cause. Enter state expiry – a compelling answer to our growing state problem. In this talk, I'll dive into the analysis of Ethereum's state growth problem down to the key-value pair level, the evolution of state expiry proposals, and the latest research on Ethereum's state expiry solutions.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
- "doNotRecord": true,
- "keywords": [],
+ "doNotRecord": false,
"tags": [
- "Gaming",
- "Autonomous World",
- "Autonomous World",
- "Gaming"
+ "Core Protocol",
+ "Protocol Design",
+ "Verkle trees",
+ "state",
+ "expiry",
+ "Core Protocol",
+ "Protocol Design",
+ "Verkle trees"
],
- "language": "en",
- "speakers": [
- "toniya-sundaram",
- "scott-mccabe"
+ "keywords": [
+ "Statelessness",
+ "State expiry"
],
+ "duration": 1345,
+ "language": "en",
+ "sources_swarmHash": "a17917322f9b68b641f7a7bb0aff74f02310d39e0fe79821d91feb668a19936e",
+ "sources_youtubeId": "UJrM6BOG7zk",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731556500000,
- "slot_end": 1731556800000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1uN2SOUzGZIHw0d3Pw3RkvvmxeEi6RqnN2J0-JbWUMHI"
+ "slot_start": 1731468600000,
+ "slot_end": 1731470400000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/18L4p0t-mR02cVw6JDvMHqUal5ARSQzWsubskb_x8FzA",
+ "resources_slides": null,
+ "speakers": [
+ "han"
+ ]
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -317822,11 +317169,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -317961,8 +317303,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -318147,6 +317487,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -318583,6 +317924,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -318609,6 +317951,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -318672,8 +318015,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -318757,6 +318098,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -318882,6 +318224,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -319122,6 +318466,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -319131,8 +318476,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -319145,47 +318488,52 @@
},
{
"session": {
- "id": "everything-you-need-to-know-about-state-expiry",
- "sourceId": "MZXQKJ",
- "title": "Everything you need to know about state expiry",
- "description": "State growth is a ticking time bomb for Ethereum, yet concrete solutions remain elusive. While statelessness offers promise, it doesn't address the root cause. Enter state expiry – a compelling answer to our growing state problem. In this talk, I'll dive into the analysis of Ethereum's state growth problem down to the key-value pair level, the evolution of state expiry proposals, and the latest research on Ethereum's state expiry solutions.",
+ "id": "evm-charts-2024-whats-hot-whats-not",
+ "sourceId": "R3UPGT",
+ "title": "EVM Charts 2024: What's hot? What's not?",
+ "description": "Thanks to the openness and transparency of blockchain we can study how developers actually use it. In this session we will compare the usage of EVM on mainnet from the last Devcon to this Devcon. Including questions like:\r\n* Which opcodes have become more/less popular?\r\n* Which precompiles have become more/less popular?\r\n* Has average memory consumption increased/decreased?\r\n* How actively are new features being used?\r\n* Are transactions getting more complicated?",
"track": "Core Protocol",
- "type": "Talk",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"tags": [
"Core Protocol",
- "Protocol Design",
- "Verkle trees",
- "state",
- "expiry",
+ "Architecture",
+ "Gas",
+ "EVM",
+ "trend",
+ "usage",
+ "Architecture",
"Core Protocol",
- "Protocol Design",
- "Verkle trees"
+ "Gas"
],
"keywords": [
- "Statelessness",
- "State expiry"
+ "Opcodes",
+ "Precompiles",
+ "EVM Metrics",
+ "Protocol Optimization",
+ "Statistics",
+ "evm usage trends"
],
- "duration": 1345,
+ "duration": 445,
"language": "en",
- "sources_swarmHash": "a17917322f9b68b641f7a7bb0aff74f02310d39e0fe79821d91feb668a19936e",
- "sources_youtubeId": "UJrM6BOG7zk",
+ "sources_swarmHash": "557c6cca7b7b2b59d76ce07897cfbc711c0cf196474cb55b4bf76b0106349118",
+ "sources_youtubeId": "m1tdQfaKt7Q",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343b629dbb7a90e1a11f0b.vtt",
+ "transcript_text": " Hello everyone, good morning. Welcome to this presentation. We're gonna see some statistics about EVM, especially we're gonna see some statistics about the firm EVM especially we're gonna compare some data and we collected data from 100,000 blocks before last DEF CON and 100,000 blocks before this DEF CON and we're gonna see what changed. I'm Dominic Britsch one of the lead auditors and co-founders at Chain Security. So, let's dive right in. But first, I have a question to you. What do you think is the most popular opcode used in the EVM? It's push1. It's mainly used to push small constants onto the stack. Next is push true and it's for larger constants and this one is especially used to push jump targets onto the stack. Third in row is jump test this marks jump test in EVM code and you might wonder why we don't see the jump instruction itself being used heavily and this is due to in the EVM code and you might wonder why we don't see the jump instruction itself being used heavily and this is due to in the EVM we have two instructions to jump jump and jump by for conditional jump and both together roughly add up to the same number as jump test overall between the data sets of DEF CON before the DEF CON Bogota and before this DEF CON, we see no change in the most popular opcodes. Moving on to the least popular opcodes. Least popular opcode is call code. This is basically a less helpful variant of delegate call, and it's used really few times only. Log0 just emits log events with zero topics and invalid opcodes they both basically simply consume all the gas of the current context when they are called. Now prior to DEF CON 7 this changed slightly. Create made it onto the list. It became less popular. Invalid is still on the list. This one is slightly interesting as this is one of the opcodes that is dominated by one single contract. The invalid opcodes are almost exclusively used by the USDT contract. They have an assert in the cipher math library they use which produces an invalid opcode if triggered. Now especially for the least popular opcode it may be interesting to discuss some opcodes that do not appear on the list, particularly self destruct. Since the Cancun hard fork this opcode has basically become obsolete and Let's ignore some special corner cases here. It now simply transfers all the ETH of the account onwards. Investigating this, we were surprised that the opcode is still used for some cases. And yeah, even more interestingly, we saw that there are still gas tokens deploying new contracts. We don't know why this is still done. We think it's due to legacy code still being triggered by some contracts. Let's have a quick look at the new opcodes introduced since last DEF CON. Keep in mind that all contracts deployed before these opccode were introduced won't use them. So all execution you see here must be from recently deployed contracts. Push0 is already used for 0.7 of all opcode we've seen. So this new opcode is already used more than, for example, call data load or MUL. You might wonder why T-Store is used more than T-Load because in a typical re-entrancy pattern, you have T-Store, T-Load, T-Store. Now, what about pre-compiles? Prior to DEF CON 6, EC-Recall was by far the most heavily used pre-compile. It was mainly used by OpenSees C-Port contract for signature verification. Keep in mind that we only have 11 million EVM transactions in our data set, so 2 million users is quite a lot. For SHA-2-256 the heaviest user was the EF2 deposit contract and identity which is mainly used in Viper for memory operations. Now before DEFCON 7 we see way less easy recover operation. The far heaviest users now are permit 2 and wormhole contract. For SHA-2-256 the heaviest users are the if-to-deposit contract and eigenlayer. And we saw that Vipers popularity rose and we see this reflected in the identity opcode. The least popular opcode, interesting here, it's one single contract that was all the blank two calls. Transaction complexity, the number of calls per transaction went down while the memory consumption decreased. So super quick summary, PUS0 is super hot, easy recover is useless and there are more calls per transaction. We've prepared a blog post which is not fully ready yet but will be published soon. It will have a full description of the data more plots more results thank you thank you thank you Dominic for the short presentation insightful one of course do you have Mari saya cuba. Ya, menarik untuk melihat bagaimana Create adalah salah satu kode op. Adakah anda mempunyai sebab atau keadaan mengenai mengapa itu berlaku? Saya cukup pasti kerana Create 2 menjadi lebih biasa dan kemudian statistik itu berpisah, betul? Betul, ya. Okey. Terima kasih. I'm pretty sure because create two became more common and then the statistics are split, right? Right, yeah. Okay. Thanks. Next question? Okay. What can we do with all these new findings? I think it's important for the core devs and the people discussing the EIP stuff, especially for the opcodes. It's really good for them to see, right, that Push 2, a new edition, the recently introduced, is really used heavily and has an impact, and they can take a look at the statistic and see what isn't used so heavily. But of course it's hard to deprecate something right because we still have contracts relying on them. Thank you. Last question.",
"eventId": "devcon-7",
- "slot_start": 1731468600000,
- "slot_end": 1731470400000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/18L4p0t-mR02cVw6JDvMHqUal5ARSQzWsubskb_x8FzA",
+ "slot_start": 1731471000000,
+ "slot_end": 1731471600000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1jchtIsIrvcgl2q1AJ62ke7MdCNqf6zK1fAUfSJtbTac",
"resources_slides": null,
"speakers": [
- "han"
+ "dominic-bruetsch"
]
},
"vector": [
@@ -319957,9 +319305,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -319987,19 +319332,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -320016,6 +319348,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -320134,7 +319467,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -320161,6 +319493,11 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -320176,6 +319513,15 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -320501,13 +319847,12 @@
0,
0,
0,
- 0,
2,
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -320524,60 +319869,35 @@
},
{
"session": {
- "id": "evm-charts-2024-whats-hot-whats-not",
- "sourceId": "R3UPGT",
- "title": "EVM Charts 2024: What's hot? What's not?",
- "description": "Thanks to the openness and transparency of blockchain we can study how developers actually use it. In this session we will compare the usage of EVM on mainnet from the last Devcon to this Devcon. Including questions like:\r\n* Which opcodes have become more/less popular?\r\n* Which precompiles have become more/less popular?\r\n* Has average memory consumption increased/decreased?\r\n* How actively are new features being used?\r\n* Are transactions getting more complicated?",
- "track": "Core Protocol",
+ "id": "evm-memory-repricing-and-gentest",
+ "sourceId": "MTWH38",
+ "title": "EVM Memory Repricing & Gentest",
+ "description": "Memory is a critical resource that enables complex computations within the Ethereum Virtual Machine (EVM). The cost of using memory, designed to prevent its abuse, has not been revised since the inception of Ethereum. However, efficiency gains from hardware advancements and client code optimizations warrants periodic repricing of this cost. We explore possible ways to make memory more accessible.",
+ "track": "[CLS] EPF Day",
"type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Research",
"featured": false,
- "doNotRecord": false,
+ "doNotRecord": true,
+ "keywords": [],
"tags": [
- "Core Protocol",
- "Architecture",
- "Gas",
- "EVM",
- "trend",
- "usage",
- "Architecture",
- "Core Protocol",
- "Gas"
- ],
- "keywords": [
- "Opcodes",
- "Precompiles",
- "EVM Metrics",
- "Protocol Optimization",
- "Statistics",
- "evm usage trends"
+ "EVM-equivalent"
],
- "duration": 445,
"language": "en",
- "sources_swarmHash": "557c6cca7b7b2b59d76ce07897cfbc711c0cf196474cb55b4bf76b0106349118",
- "sources_youtubeId": "m1tdQfaKt7Q",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343b629dbb7a90e1a11f0b.vtt",
- "transcript_text": " Hello everyone, good morning. Welcome to this presentation. We're gonna see some statistics about EVM, especially we're gonna see some statistics about the firm EVM especially we're gonna compare some data and we collected data from 100,000 blocks before last DEF CON and 100,000 blocks before this DEF CON and we're gonna see what changed. I'm Dominic Britsch one of the lead auditors and co-founders at Chain Security. So, let's dive right in. But first, I have a question to you. What do you think is the most popular opcode used in the EVM? It's push1. It's mainly used to push small constants onto the stack. Next is push true and it's for larger constants and this one is especially used to push jump targets onto the stack. Third in row is jump test this marks jump test in EVM code and you might wonder why we don't see the jump instruction itself being used heavily and this is due to in the EVM code and you might wonder why we don't see the jump instruction itself being used heavily and this is due to in the EVM we have two instructions to jump jump and jump by for conditional jump and both together roughly add up to the same number as jump test overall between the data sets of DEF CON before the DEF CON Bogota and before this DEF CON, we see no change in the most popular opcodes. Moving on to the least popular opcodes. Least popular opcode is call code. This is basically a less helpful variant of delegate call, and it's used really few times only. Log0 just emits log events with zero topics and invalid opcodes they both basically simply consume all the gas of the current context when they are called. Now prior to DEF CON 7 this changed slightly. Create made it onto the list. It became less popular. Invalid is still on the list. This one is slightly interesting as this is one of the opcodes that is dominated by one single contract. The invalid opcodes are almost exclusively used by the USDT contract. They have an assert in the cipher math library they use which produces an invalid opcode if triggered. Now especially for the least popular opcode it may be interesting to discuss some opcodes that do not appear on the list, particularly self destruct. Since the Cancun hard fork this opcode has basically become obsolete and Let's ignore some special corner cases here. It now simply transfers all the ETH of the account onwards. Investigating this, we were surprised that the opcode is still used for some cases. And yeah, even more interestingly, we saw that there are still gas tokens deploying new contracts. We don't know why this is still done. We think it's due to legacy code still being triggered by some contracts. Let's have a quick look at the new opcodes introduced since last DEF CON. Keep in mind that all contracts deployed before these opccode were introduced won't use them. So all execution you see here must be from recently deployed contracts. Push0 is already used for 0.7 of all opcode we've seen. So this new opcode is already used more than, for example, call data load or MUL. You might wonder why T-Store is used more than T-Load because in a typical re-entrancy pattern, you have T-Store, T-Load, T-Store. Now, what about pre-compiles? Prior to DEF CON 6, EC-Recall was by far the most heavily used pre-compile. It was mainly used by OpenSees C-Port contract for signature verification. Keep in mind that we only have 11 million EVM transactions in our data set, so 2 million users is quite a lot. For SHA-2-256 the heaviest user was the EF2 deposit contract and identity which is mainly used in Viper for memory operations. Now before DEFCON 7 we see way less easy recover operation. The far heaviest users now are permit 2 and wormhole contract. For SHA-2-256 the heaviest users are the if-to-deposit contract and eigenlayer. And we saw that Vipers popularity rose and we see this reflected in the identity opcode. The least popular opcode, interesting here, it's one single contract that was all the blank two calls. Transaction complexity, the number of calls per transaction went down while the memory consumption decreased. So super quick summary, PUS0 is super hot, easy recover is useless and there are more calls per transaction. We've prepared a blog post which is not fully ready yet but will be published soon. It will have a full description of the data more plots more results thank you thank you thank you Dominic for the short presentation insightful one of course do you have Mari saya cuba. Ya, menarik untuk melihat bagaimana Create adalah salah satu kode op. Adakah anda mempunyai sebab atau keadaan mengenai mengapa itu berlaku? Saya cukup pasti kerana Create 2 menjadi lebih biasa dan kemudian statistik itu berpisah, betul? Betul, ya. Okey. Terima kasih. I'm pretty sure because create two became more common and then the statistics are split, right? Right, yeah. Okay. Thanks. Next question? Okay. What can we do with all these new findings? I think it's important for the core devs and the people discussing the EIP stuff, especially for the opcodes. It's really good for them to see, right, that Push 2, a new edition, the recently introduced, is really used heavily and has an impact, and they can take a look at the statistic and see what isn't used so heavily. But of course it's hard to deprecate something right because we still have contracts relying on them. Thank you. Last question.",
- "eventId": "devcon-7",
- "slot_start": 1731471000000,
- "slot_end": 1731471600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1jchtIsIrvcgl2q1AJ62ke7MdCNqf6zK1fAUfSJtbTac",
- "resources_slides": null,
"speakers": [
- "dominic-bruetsch"
- ]
+ "raxhvl"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731468600000,
+ "slot_end": 1731469500000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1e6KETyrkOalajDAo2_dDl3Cg0oUXzpb7Ehl8aawzChY"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -320589,6 +319909,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -321344,7 +320665,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -321387,7 +320707,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -321532,7 +320851,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -321553,7 +320871,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -321647,7 +320964,8 @@
0,
0,
0,
- 2,
+ 0,
+ 0,
2,
0,
0,
@@ -321908,35 +321226,52 @@
},
{
"session": {
- "id": "evm-memory-repricing-and-gentest",
- "sourceId": "MTWH38",
- "title": "EVM Memory Repricing & Gentest",
- "description": "Memory is a critical resource that enables complex computations within the Ethereum Virtual Machine (EVM). The cost of using memory, designed to prevent its abuse, has not been revised since the inception of Ethereum. However, efficiency gains from hardware advancements and client code optimizations warrants periodic repricing of this cost. We explore possible ways to make memory more accessible.",
- "track": "[CLS] EPF Day",
- "type": "Lightning Talk",
+ "id": "evm-object-format-eof-history-and-motivation",
+ "sourceId": "SEUZGU",
+ "title": "EVM Object Format (EOF) - History and motivation",
+ "description": "EOF is one of the important parts of the upcoming Pectra upgrade, delivering long-standing feature requests to the EVM. This talk aims to provide insight into its history, significance, and role in Ethereum and EVM improvement, and explore the rationale for including it in the next upgrade, its potential impacts and implications, as well as long-term advantages and possible challenges.",
+ "track": "Core Protocol",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
- "doNotRecord": true,
- "keywords": [],
+ "doNotRecord": false,
"tags": [
- "EVM-equivalent"
+ "Core Protocol",
+ "developer",
+ "experience",
+ "Core",
+ "Protocol"
],
- "language": "en",
- "speakers": [
- "raxhvl"
+ "keywords": [
+ "EVM",
+ "Developer Experience"
],
+ "duration": 1503,
+ "language": "en",
+ "sources_swarmHash": "f05d6e3e2b2f1bbc704ce9e98664b8dac849778797f474d69fa7dd09e007a496",
+ "sources_youtubeId": "X2mlptWzphc",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731468600000,
- "slot_end": 1731469500000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1e6KETyrkOalajDAo2_dDl3Cg0oUXzpb7Ehl8aawzChY"
+ "slot_start": 1731400200000,
+ "slot_end": 1731402000000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1V-NCCshtl60AkHuWhlJDZ4XszkThsUvFQ_L8gM-hAro",
+ "resources_slides": null,
+ "speakers": [
+ "danno-ferrin"
+ ]
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -321948,7 +321283,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -322701,6 +322035,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -322856,6 +322191,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -322984,13 +322320,8 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
+ 2,
0,
0,
0,
@@ -323250,7 +322581,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -323263,50 +322593,45 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "evm-object-format-eof-history-and-motivation",
- "sourceId": "SEUZGU",
- "title": "EVM Object Format (EOF) - History and motivation",
- "description": "EOF is one of the important parts of the upcoming Pectra upgrade, delivering long-standing feature requests to the EVM. This talk aims to provide insight into its history, significance, and role in Ethereum and EVM improvement, and explore the rationale for including it in the next upgrade, its potential impacts and implications, as well as long-term advantages and possible challenges.",
+ "id": "evm-object-format-eof-managing-the-bytecode-chaos",
+ "sourceId": "UU9BTK",
+ "title": "EVM Object Format (EOF): Managing the Bytecode Chaos",
+ "description": "Currently, EVM bytecode, while being powerful and simple, is lacking structure. This leads to many complexities when introducing new EIPs and maintaining backwards compatibility.\r\n\r\nIn this talk, we illustrate some use cases of the EVM Object Format (EOF). Next, we provide a quick overview of the main changes introduced by the EOF and related EIPs, along with code examples. Finally, we discuss potential benefits and drawbacks that could arise with the introduction of EOF",
"track": "Core Protocol",
"type": "Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Core Protocol",
- "developer",
- "experience",
- "Core",
- "Protocol"
- ],
"keywords": [
- "EVM",
- "Developer Experience"
+ "EOF",
+ "EIP",
+ "upgrades"
+ ],
+ "tags": [
+ "Ethereum Roadmap",
+ "Protocol Design",
+ "Security",
+ "upgrade",
+ "Ethereum Roadmap",
+ "Protocol Design",
+ "Security"
],
- "duration": 1503,
"language": "en",
- "sources_swarmHash": "f05d6e3e2b2f1bbc704ce9e98664b8dac849778797f474d69fa7dd09e007a496",
- "sources_youtubeId": "X2mlptWzphc",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731400200000,
- "slot_end": 1731402000000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1V-NCCshtl60AkHuWhlJDZ4XszkThsUvFQ_L8gM-hAro",
- "resources_slides": null,
"speakers": [
- "danno-ferrin"
- ]
+ "alex-murashkin"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731552300000,
+ "slot_end": 1731554100000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/11DBlWa1M4JLbQS2Ik4OU6nxzNoPj1nINFepAqbY2qIk"
},
"vector": [
0,
@@ -324058,6 +323383,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -324080,9 +323406,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -324106,6 +323429,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -324236,7 +323560,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -324252,6 +323575,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -324366,8 +323690,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -324644,39 +323966,34 @@
},
{
"session": {
- "id": "evm-object-format-eof-managing-the-bytecode-chaos",
- "sourceId": "UU9BTK",
- "title": "EVM Object Format (EOF): Managing the Bytecode Chaos",
- "description": "Currently, EVM bytecode, while being powerful and simple, is lacking structure. This leads to many complexities when introducing new EIPs and maintaining backwards compatibility.\r\n\r\nIn this talk, we illustrate some use cases of the EVM Object Format (EOF). Next, we provide a quick overview of the main changes introduced by the EOF and related EIPs, along with code examples. Finally, we discuss potential benefits and drawbacks that could arise with the introduction of EOF",
+ "id": "evmmax-fast-modular-arithmetic-in-evm",
+ "sourceId": "7CWEHH",
+ "title": "EVMMAX. Fast Modular Arithmetic in EVM",
+ "description": "On the top of EVM Object Format we build an extension which allows contract developers to implement optimized advanced cryptography functions. This feature allows us to implement existing and future ECC precompiles counterparts directly in EVM. Adding new ECC functions (i.e. bls precompiles or functions based on a new, unknown yet, elliptic curve) to the protocol won't require introducing new precompiles. It can be achieved easier and without any risk for the consensus.",
"track": "Core Protocol",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
"EOF",
- "EIP",
- "upgrades"
+ "EVM"
],
"tags": [
- "Ethereum Roadmap",
- "Protocol Design",
- "Security",
- "upgrade",
- "Ethereum Roadmap",
- "Protocol Design",
- "Security"
+ "Cryptography",
+ "EVM",
+ "Cryptography"
],
"language": "en",
"speakers": [
- "alex-murashkin"
+ "rodiazet"
],
"eventId": "devcon-7",
- "slot_start": 1731552300000,
- "slot_end": 1731554100000,
+ "slot_start": 1731556800000,
+ "slot_end": 1731558600000,
"slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/11DBlWa1M4JLbQS2Ik4OU6nxzNoPj1nINFepAqbY2qIk"
+ "resources_presentation": "https://docs.google.com/presentation/d/1fh8W3duOjm-uN-PLpwXQdH39CtC5VtYT9yOjlpTE8hk"
},
"vector": [
0,
@@ -325431,6 +324748,16 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
6,
0,
0,
@@ -325477,7 +324804,9 @@
0,
0,
0,
- 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -325757,27 +325086,12 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -325996,9 +325310,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -326014,40 +325328,46 @@
},
{
"session": {
- "id": "evmmax-fast-modular-arithmetic-in-evm",
- "sourceId": "7CWEHH",
- "title": "EVMMAX. Fast Modular Arithmetic in EVM",
- "description": "On the top of EVM Object Format we build an extension which allows contract developers to implement optimized advanced cryptography functions. This feature allows us to implement existing and future ECC precompiles counterparts directly in EVM. Adding new ECC functions (i.e. bls precompiles or functions based on a new, unknown yet, elliptic curve) to the protocol won't require introducing new precompiles. It can be achieved easier and without any risk for the consensus.",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "evolution-of-scams",
+ "sourceId": "WZWPE9",
+ "title": "Evolution of Scams",
+ "description": "The goal of this talk will be to give a quick history of the evolution of scams and the new techniques employed to combat them. I was previously the co-founder of Wallet Guard, which has since been acquired by Consensys. I now am responsible for the research and development of the security engine employed by MetaMask to protect its users.",
+ "track": "Security",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "EOF",
- "EVM"
- ],
"tags": [
- "Cryptography",
- "EVM",
- "Cryptography"
+ "metamask",
+ "Hacks",
+ "Security"
],
- "language": "en",
- "speakers": [
- "rodiazet"
+ "keywords": [
+ "Security",
+ "Drainers",
+ "MetaMask"
],
+ "duration": 558,
+ "language": "en",
+ "sources_swarmHash": "10b2a71955b16582577039f8e25b02ba983b4c003975aa7d0a9f7e11ca72f537",
+ "sources_youtubeId": "SgkEwSDkBnI",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733381c3a168eb535e0521e.vtt",
+ "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you",
"eventId": "devcon-7",
- "slot_start": 1731556800000,
- "slot_end": 1731558600000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1fh8W3duOjm-uN-PLpwXQdH39CtC5VtYT9yOjlpTE8hk"
+ "slot_start": 1731408600000,
+ "slot_end": 1731409200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1fLuDyHluumURppoq7gyTD9d7Z-wKLdy5qsCg-Tytso0",
+ "resources_slides": null,
+ "speakers": [
+ "ohm"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -326381,11 +325701,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -326797,6 +326117,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -326809,7 +326130,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -327003,7 +326323,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -327048,6 +326367,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -327123,6 +326443,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -327362,7 +326683,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -327374,54 +326694,48 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "evolution-of-scams",
- "sourceId": "WZWPE9",
- "title": "Evolution of Scams",
- "description": "The goal of this talk will be to give a quick history of the evolution of scams and the new techniques employed to combat them. I was previously the co-founder of Wallet Guard, which has since been acquired by Consensys. I now am responsible for the research and development of the security engine employed by MetaMask to protect its users.",
- "track": "Security",
+ "id": "exploring-auction-mechanisms-in-protocol-design",
+ "sourceId": "WAKEL9",
+ "title": "Exploring Auction Mechanisms in Protocol Design",
+ "description": "Auction mechanisms are fascinating, and so are protocol designs. When you put both together, things get really interesting. In this talk, we'll dive into various auction mechanisms and see how they shape protocol design choices. We'll cover key aspects like the timing game, MEV burn, and participant trusts. Then we will look at case studies: Ethereum, Optimism, and Arbitrum. For each case, we'll conclude how protocol impacts auction or vice versa.",
+ "track": "Cryptoeconomics",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "expertise": "Beginner",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "metamask",
- "Hacks",
- "Security"
- ],
"keywords": [
- "Security",
- "Drainers",
- "MetaMask"
+ "Auction"
+ ],
+ "tags": [
+ "Core Protocol",
+ "Economics",
+ "MEV",
+ "auction",
+ "Core Protocol",
+ "Economics",
+ "MEV"
],
- "duration": 558,
"language": "en",
- "sources_swarmHash": "10b2a71955b16582577039f8e25b02ba983b4c003975aa7d0a9f7e11ca72f537",
- "sources_youtubeId": "SgkEwSDkBnI",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733381c3a168eb535e0521e.vtt",
- "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you",
+ "speakers": [
+ "terence"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731408600000,
- "slot_end": 1731409200000,
+ "slot_start": 1731485400000,
+ "slot_end": 1731486000000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1fLuDyHluumURppoq7gyTD9d7Z-wKLdy5qsCg-Tytso0",
- "resources_slides": null,
- "speakers": [
- "ohm"
- ]
+ "resources_presentation": "https://docs.google.com/presentation/d/1SW7qjLygGhslLlaFTINPgoKm5AVWrY8ItfsnIvPnUq4"
},
"vector": [
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -328170,7 +327484,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -328188,6 +327501,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -328203,6 +327517,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -328422,10 +327737,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -328732,10 +328043,9 @@
0,
0,
0,
- 2,
- 0,
0,
0,
+ 2,
0,
2,
0,
@@ -328749,47 +328059,43 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "exploring-auction-mechanisms-in-protocol-design",
- "sourceId": "WAKEL9",
- "title": "Exploring Auction Mechanisms in Protocol Design",
- "description": "Auction mechanisms are fascinating, and so are protocol designs. When you put both together, things get really interesting. In this talk, we'll dive into various auction mechanisms and see how they shape protocol design choices. We'll cover key aspects like the timing game, MEV burn, and participant trusts. Then we will look at case studies: Ethereum, Optimism, and Arbitrum. For each case, we'll conclude how protocol impacts auction or vice versa.",
- "track": "Cryptoeconomics",
+ "id": "exploring-mud-worlds-with-blockscout",
+ "sourceId": "QTLXWL",
+ "title": "Exploring MUD worlds with Blockscout",
+ "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\nShowcase of the Blockscout features that help users and developers explore any MUD world on-chain.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
"type": "Lightning Talk",
"expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Auction"
+ "Block",
+ "Explorers"
],
"tags": [
- "Core Protocol",
- "Economics",
- "MEV",
- "auction",
- "Core Protocol",
- "Economics",
- "MEV"
+ "Appchains",
+ "Interface"
],
"language": "en",
"speakers": [
- "terence"
+ "kirill-fedoseev"
],
"eventId": "devcon-7",
- "slot_start": 1731485400000,
- "slot_end": 1731486000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1SW7qjLygGhslLlaFTINPgoKm5AVWrY8ItfsnIvPnUq4"
+ "slot_start": 1731555300000,
+ "slot_end": 1731555600000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1K-pTNAyptFNuvxYIVpjPCZK8H_NM7O6asR23AlFcIro"
},
"vector": [
0,
0,
- 6,
0,
0,
0,
@@ -328800,6 +328106,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -329541,8 +328848,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -329558,7 +328863,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -329574,7 +328878,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -329682,6 +328985,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -330122,33 +329426,42 @@
},
{
"session": {
- "id": "exploring-mud-worlds-with-blockscout",
- "sourceId": "QTLXWL",
- "title": "Exploring MUD worlds with Blockscout",
- "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\nShowcase of the Blockscout features that help users and developers explore any MUD world on-chain.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Lightning Talk",
- "expertise": "Beginner",
+ "id": "exploring-proof-of-personhood-privacy-biometrics-and-why-it-needs-ethereum",
+ "sourceId": "TVSAZU",
+ "title": "Exploring Proof of Personhood: Privacy, Biometrics, and Why It Needs Ethereum.",
+ "description": "In this session, Remco Bloemen will explore the urgent need for proof of personhood and privacy in a digital-first world. Using insights from Vitalik’s blogpost 07/23, Remco explains why Ethereum’s trustless infrastructure is key to achieving privacy-preserving identity solutions through technologies like zero-knowledge proofs (ZK) and multi-party computation (MPC). This talk is designed to educate developers on creating equitable digital identity solutions without compromising user privacy.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Block",
- "Explorers"
- ],
"tags": [
- "Appchains",
- "Interface"
+ "Identity",
+ "Privacy",
+ "Zero-Knowledge"
],
- "language": "en",
- "speakers": [
- "kirill-fedoseev"
+ "keywords": [
+ "N/A"
],
+ "duration": 1479,
+ "language": "en",
+ "sources_swarmHash": "cefd278367af0d091b677cea10e548bc18dedd7bdc45fcbc3702cd2f211fcf46",
+ "sources_youtubeId": "q3rpu8aDRA8",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731555300000,
- "slot_end": 1731555600000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1K-pTNAyptFNuvxYIVpjPCZK8H_NM7O6asR23AlFcIro"
+ "slot_start": 1731409200000,
+ "slot_end": 1731411000000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1tSAo9i2l_HRD2OBB2F6SjjF1Z6zy8MLucrc8FO5rWQs",
+ "resources_slides": null,
+ "speakers": [
+ "remco-bloeman"
+ ]
},
"vector": [
0,
@@ -330157,13 +329470,13 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -330912,6 +330225,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -330947,6 +330262,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -331013,6 +330329,15 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -331045,7 +330370,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -331232,20 +330556,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -331464,9 +330774,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
2,
0,
@@ -331486,51 +330796,48 @@
},
{
"session": {
- "id": "exploring-proof-of-personhood-privacy-biometrics-and-why-it-needs-ethereum",
- "sourceId": "TVSAZU",
- "title": "Exploring Proof of Personhood: Privacy, Biometrics, and Why It Needs Ethereum.",
- "description": "In this session, Remco Bloemen will explore the urgent need for proof of personhood and privacy in a digital-first world. Using insights from Vitalik’s blogpost 07/23, Remco explains why Ethereum’s trustless infrastructure is key to achieving privacy-preserving identity solutions through technologies like zero-knowledge proofs (ZK) and multi-party computation (MPC). This talk is designed to educate developers on creating equitable digital identity solutions without compromising user privacy.",
- "track": "Real World Ethereum",
+ "id": "exploring-the-future-of-account-abstraction",
+ "sourceId": "S7NYUJ",
+ "title": "Exploring the Future of Account Abstraction",
+ "description": "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).",
+ "track": "Core Protocol",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
- "featured": false,
+ "audience": "Developer",
+ "featured": true,
"doNotRecord": false,
- "tags": [
- "Identity",
- "Privacy",
- "Zero-Knowledge"
- ],
"keywords": [
- "N/A"
+ "AA",
+ "roadmap"
+ ],
+ "tags": [
+ "Ethereum Roadmap",
+ "In-protocol Account Abstraction",
+ "Account Abstraction",
+ "aa",
+ "roadmap",
+ "Account Abstraction",
+ "Ethereum Roadmap",
+ "In-protocol Account Abstraction"
],
- "duration": 1479,
"language": "en",
- "sources_swarmHash": "cefd278367af0d091b677cea10e548bc18dedd7bdc45fcbc3702cd2f211fcf46",
- "sources_youtubeId": "q3rpu8aDRA8",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731409200000,
- "slot_end": 1731411000000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1tSAo9i2l_HRD2OBB2F6SjjF1Z6zy8MLucrc8FO5rWQs",
- "resources_slides": null,
"speakers": [
- "remco-bloeman"
- ]
+ "yoav-weiss"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731560400000,
+ "slot_end": 1731562200000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1-B8ZzQJNuc1_e9BR0rIfLQYc9lXZ8nuO1aV56lK7dKM"
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
- 6,
0,
0,
0,
@@ -332288,7 +331595,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -332392,12 +331698,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -332472,6 +331772,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -332498,6 +331799,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -332607,6 +331909,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -332841,9 +332145,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -332859,50 +332163,47 @@
},
{
"session": {
- "id": "exploring-the-future-of-account-abstraction",
- "sourceId": "S7NYUJ",
- "title": "Exploring the Future of Account Abstraction",
- "description": "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).",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "exploring-various-approaches-to-achieve-effective-decentralization-for-intent-based-protocols",
+ "sourceId": "LGZYYW",
+ "title": "Exploring various approaches to achieve effective decentralization for Intent-Based protocols",
+ "description": "Intents are emerging as the gold standard for transacting on-chain. However, they do come with decentralization trade-offs. In this talk, I'd like to present the status quo, various architectures, and new tradeoffs in terms of where they fit in the trilemma of fees, execution speed, and execution guarantees. The objective is to achieve maximum decentralization while maintaining a great UX and efficiency.",
+ "track": "Usability",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developer",
- "featured": true,
+ "audience": "Engineering",
+ "featured": false,
"doNotRecord": false,
"keywords": [
- "AA",
- "roadmap"
+ "TEE"
],
"tags": [
- "Ethereum Roadmap",
- "In-protocol Account Abstraction",
- "Account Abstraction",
- "aa",
- "roadmap",
- "Account Abstraction",
- "Ethereum Roadmap",
- "In-protocol Account Abstraction"
+ "TEE",
+ "Decentralization",
+ "Homomorphic Encryption",
+ "Intents",
+ "MPC",
+ "ZKP"
],
"language": "en",
"speakers": [
- "yoav-weiss"
+ "mounir-benchemled"
],
"eventId": "devcon-7",
- "slot_start": 1731560400000,
- "slot_end": 1731562200000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1-B8ZzQJNuc1_e9BR0rIfLQYc9lXZ8nuO1aV56lK7dKM"
+ "slot_start": 1731558000000,
+ "slot_end": 1731558600000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1LaXJZlFuHU9E1WzvaA5EEprE3pUrcWOtPgm0VCJNCN8"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -333697,12 +332998,8 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
+ 2,
0,
0,
0,
@@ -333722,6 +333019,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -333735,6 +333033,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -333746,6 +333046,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -333838,7 +333139,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -333865,7 +333165,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -333977,7 +333276,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -334211,9 +333509,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -334229,47 +333527,50 @@
},
{
"session": {
- "id": "exploring-various-approaches-to-achieve-effective-decentralization-for-intent-based-protocols",
- "sourceId": "LGZYYW",
- "title": "Exploring various approaches to achieve effective decentralization for Intent-Based protocols",
- "description": "Intents are emerging as the gold standard for transacting on-chain. However, they do come with decentralization trade-offs. In this talk, I'd like to present the status quo, various architectures, and new tradeoffs in terms of where they fit in the trilemma of fees, execution speed, and execution guarantees. The objective is to achieve maximum decentralization while maintaining a great UX and efficiency.",
- "track": "Usability",
- "type": "Lightning Talk",
+ "id": "fair-combinatorial-auction-for-trade-intents-how-to-design-mechanisms-without-a-numeraire",
+ "sourceId": "AAYWGY",
+ "title": "Fair combinatorial auction for trade intents: how to design mechanisms without a numeraire",
+ "description": "When designing mechanisms on the blockchain, there may be no single asset that can be used to reallocate the benefits of participating in the mechanism among its participants. Hence, the designer cannot separately address achieving an objective and sharing the resulting gains, as the objective affects how/whether these gains can be shared. This raises fairness concerns. We discuss the relevance of this issue for trade intent auctions and propose a novel mechanism: the fair combinatorial auction.",
+ "track": "Cryptoeconomics",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Academic",
"featured": false,
"doNotRecord": false,
"keywords": [
- "TEE"
+ "Batch auctions",
+ "dutch auctions",
+ "auctions",
+ "CoW Swap",
+ "research"
],
"tags": [
- "TEE",
- "Decentralization",
- "Homomorphic Encryption",
+ "Mechanism design",
"Intents",
- "MPC",
- "ZKP"
+ "research",
+ "Intents",
+ "Mechanism design"
],
"language": "en",
"speakers": [
- "mounir-benchemled"
+ "andrea-canidio"
],
"eventId": "devcon-7",
- "slot_start": 1731558000000,
- "slot_end": 1731558600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1LaXJZlFuHU9E1WzvaA5EEprE3pUrcWOtPgm0VCJNCN8"
+ "slot_start": 1731650400000,
+ "slot_end": 1731652200000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1LquF7sJyYCfQkhUppmol316cCEsxjzZbhvuKG4u7QnU"
},
"vector": [
0,
0,
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -335017,6 +334318,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -335064,11 +334366,42 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -335088,7 +334421,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -335102,8 +334434,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -335115,7 +334445,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -335251,6 +334580,38 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -335345,69 +334706,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -335578,7 +334876,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -335588,6 +334885,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -335596,45 +334894,50 @@
},
{
"session": {
- "id": "fair-combinatorial-auction-for-trade-intents-how-to-design-mechanisms-without-a-numeraire",
- "sourceId": "AAYWGY",
- "title": "Fair combinatorial auction for trade intents: how to design mechanisms without a numeraire",
- "description": "When designing mechanisms on the blockchain, there may be no single asset that can be used to reallocate the benefits of participating in the mechanism among its participants. Hence, the designer cannot separately address achieving an objective and sharing the resulting gains, as the objective affects how/whether these gains can be shared. This raises fairness concerns. We discuss the relevance of this issue for trade intent auctions and propose a novel mechanism: the fair combinatorial auction.",
- "track": "Cryptoeconomics",
- "type": "Talk",
+ "id": "farcaster-frames-building-embeddable-ethereum-apps",
+ "sourceId": "NPGET3",
+ "title": "Farcaster frames: building embeddable Ethereum apps",
+ "description": "Frames are an open standard for creating embeddable, interactive apps in social media feeds and on the web. They help solve one of the hardest problems for Ethereum dapp developers: distribution. Although frames originated on Farcaster, it's now possible to build cross-platform frames that work on Farcaster, Lens, XMTP, and the open web. In this hands on workshop we'll introduce the core concepts behind frames and build a simple frame app that interacts with a smart contract.",
+ "track": "Developer Experience",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Academic",
- "featured": false,
+ "audience": "Engineering",
+ "featured": true,
"doNotRecord": false,
- "keywords": [
- "Batch auctions",
- "dutch auctions",
- "auctions",
- "CoW Swap",
- "research"
- ],
"tags": [
- "Mechanism design",
- "Intents",
- "research",
- "Intents",
- "Mechanism design"
+ "Developer Infrastructure",
+ "Social",
+ "farcaster",
+ "Developer Infrastructure",
+ "Social"
],
- "language": "en",
- "speakers": [
- "andrea-canidio"
+ "keywords": [
+ "Farcaster"
],
+ "duration": 5086,
+ "language": "en",
+ "sources_swarmHash": "8e0e0c17254242e8c66955524eb158e4655137ffbc89bd6592179981209be316",
+ "sources_youtubeId": "LnEpR575FRA",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731650400000,
- "slot_end": 1731652200000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1LquF7sJyYCfQkhUppmol316cCEsxjzZbhvuKG4u7QnU"
+ "slot_start": 1731400800000,
+ "slot_end": 1731406200000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1liuvnLXBUAB0kNGDh3VePfZNkfZ-ECHpzPYsSrv_d-M",
+ "resources_slides": null,
+ "speakers": [
+ "horsefacts"
+ ]
},
"vector": [
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -336390,10 +335693,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -336564,6 +335863,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -336653,7 +335953,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -336716,6 +336015,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -336948,6 +336248,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -336957,7 +336258,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -336966,52 +336266,54 @@
},
{
"session": {
- "id": "farcaster-frames-building-embeddable-ethereum-apps",
- "sourceId": "NPGET3",
- "title": "Farcaster frames: building embeddable Ethereum apps",
- "description": "Frames are an open standard for creating embeddable, interactive apps in social media feeds and on the web. They help solve one of the hardest problems for Ethereum dapp developers: distribution. Although frames originated on Farcaster, it's now possible to build cross-platform frames that work on Farcaster, Lens, XMTP, and the open web. In this hands on workshop we'll introduce the core concepts behind frames and build a simple frame app that interacts with a smart contract.",
- "track": "Developer Experience",
- "type": "Workshop",
- "expertise": "Intermediate",
+ "id": "financial-nihilism-vs-foss-culture-the-battle-for-ethereums-soul",
+ "sourceId": "SSXAMG",
+ "title": "Financial Nihilism vs FOSS Culture: The Battle for Ethereum’s Soul",
+ "description": "In recent years, the Ethereum ecosystem has witnessed a stark dichotomy: the rise of financial nihilism through memecoins and rampant speculation on one side, and the foundational principles of the FOSS (Free and Open Source Software) community, emphasising public goods, interdependence, and intrinsic rewards, on the other. \r\n\r\nThis talk will delve into the experiences of interacting with FOSS developers, shedding light on their views and concerns regarding Ethereum’s current trajectory.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Talk",
+ "expertise": "Beginner",
"audience": "Engineering",
- "featured": true,
+ "featured": false,
"doNotRecord": false,
"tags": [
- "Developer Infrastructure",
- "Social",
- "farcaster",
- "Developer Infrastructure",
- "Social"
+ "Values",
+ "FOSS",
+ "Decentralization",
+ "culture",
+ "Decentralization",
+ "FOSS",
+ "Values"
],
"keywords": [
- "Farcaster"
+ "Culture"
],
- "duration": 5086,
+ "duration": 1584,
"language": "en",
- "sources_swarmHash": "8e0e0c17254242e8c66955524eb158e4655137ffbc89bd6592179981209be316",
- "sources_youtubeId": "LnEpR575FRA",
+ "sources_swarmHash": "d2fa049d664484b158c36db2c05b9ff461267f4ee44787a45a7ba182dabe07fc",
+ "sources_youtubeId": "sNPxhnznfEA",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673336483a168eb535d564de.vtt",
+ "transcript_text": " Hey everybody, great to see you all here. Thanks for coming out. I'm Jack Sanford. I'm the CEO and co-founder of Sherlock. Sherlock is one of the largest audit contest providers in the space. And today we're going to talk a little bit about the most common bugs found in audit contests. So if you're a protocol developer or if you want to become a protocol developer one day, you are going to be ahead of 90% of other protocol developers just by being aware of these 10 common bugs. So just a quick intro on audit contests and why you should care. Audit contests have become and are becoming one of the most popular ways to secure smart contract code before deploying a protocol to mainnet. There's been 625 audit contests run. The most have happened this year of any year. So it's really taking off 36,000 vulnerabilities found. 36 million in prizes have been paid out to thousands, tens of thousands of security experts, people who are learning to be security experts, all from finding bugs in these audit contests. And as you can see, the biggest teams in the space are using audit contests. All of these teams have done an audit contest this year in order to secure their code. So what is an audit contest? Essentially, the goal is to find bugs in code, usually critical bugs, bugs that are going to cause losses for users on mainnet. You start with a pot of money. You say, hey, here's 100k. Or in some cases, here's a million dollars. And we're going to pay people based on the bugs that they find. And anybody can participate. So it's a really great way to onboard to crypto, really great way to onboard to Web3 security, participating in audit contests. And depending on the severity of the bugs you find, so if they're critical severity, you're going to get paid more for them. If they're super unique and other people don't find them, you're going to get paid more for that. And if you find, you know, three of the four bugs that are in that protocol during that audit contest, you're going to get paid a lot of money for that. So really cool thing. And we're going to rip through super quickly the top 10 vulnerabilities that are found in audit contests these days. So number one, first depositor inflation attack in ERC4626 vaults. This is a super famous attack, really annoying because anytime you deploy a new vault on a blockchain, you're essentially exposed to this attack because the person who puts in the first deposit can essentially put in such a tiny deposit that it causes sort of a rounding issue and then all the deposits after that are a little bit messed up and the first depositor can steal funds that way and kind of DOS the vault. Second one, using transfer instead of safe transfer. So just using the transfer function in Solidity doesn't actually check the success or failure of a transfer, and it can also allow for really bad things like reentrancy with non-standard tokens such as USDT. Number three, missing validation and admin checks. So let's say you only want the owner of a contract to call a function or someone on a whitelist to call a function. A lot of times there's so many functions you just forget one, essentially, or you forget to check for something that you meant to check for. And that's what auditors are here for, and they're really good at finding that stuff. So this happens more often than you'd think. Okay, missing check for active L2 sequencer. So essentially, if you are deploying a protocol on top of an L2, like arbitrum or optimism, sometimes the sequencer goes down. Not very often, but it could happen in the future, and it could happen for long periods of time. And if you're a derivatives protocol or something where real-time information is super important, malicious actors can take advantage of stale prices because of the sequencer being down. Number five, the classic reentrancy, very first major vulnerability ever in Ethereum, the DAO hack. Basically, there are certain functions where essentially you can continue the execution outside of the function and call that very same function again and this can cause all kinds of problems there's a bunch of different like surface area for what these vulnerabilities can do but i'm sure a lot of you have heard of reentrancy already beyond transfer rebasing tokens so if you want your protocol to be able to handle any token out there, or even a pretty general set of tokens, a lot of them are non-standard. A lot of them don't conform to, you know, things that you would think that they conform to. And so smart contracts can get completely DOSed or funds can be lost because of these tokens having non-standard behavior with your functions. So rounding precision loss issues, this one has become really famous in the last 12 months, even if something is off by a couple of way or to the 18th, 17th decimal place, you can have major issues because of the way that solidity essentially, or the EVM essentially doesn't have floating point arithmetic. So it truncates things it rounds things a little bit and that can cause a lot of issues hitting the last three really quickly here using spot price instead of TWAP and Uniswap so this is something that I think we've all seen price manipulation attacks where someone basically inflates the value of a certain currency in a Uniswap pool for even one block and then does some attack using a flash loan and then it goes back down. So that one is really common, less common these days, thankfully. Incorrect implementation of upgradability. So essentially you want your contracts to be able to be upgraded, and it turns out you hard-coded something in an initializer, you hard-coded something in the constructor, and you can't actually upgrade your contracts, and you only find that out later. So that's kind of annoying, but not too big of a deal unless the initial deployment of your contracts is super critical. Last one, no slippage check in custom vaults and pools. So ERC4626 is great. Use, you know, standards whenever you can when you're developing in Solidity, because if you have non-standard pools, you can actually have your user sign up to get a trade done at one price, and then at the very next block or the very next execution, that price is completely different, and it can be off by a massive amount of percentage points. So your users can get really into trouble if you don't have slippage checks on your functions there. So that's the whole talk. If you're looking to become a protocol developer, check on these 10 things before you send your protocol to audits, and you'll be ahead of 90% of the other developers out there. Thank you, Jack. I see a question over there. When would you do an audit contest? Would it be like after you've done an audit or before you do your first audit or instead of a regular audit? What's the goal there? Yeah, it's a great question. If you can do multiple audits, I would normally say do the audit contest last because you get 300 people. It's a little bit, there's more operational complexity with it because you have to deal with 300 people. You know, Sherlock and others will deduplicate the issues for you. So if you can do a traditional audit or two before that, that's even better because you get to have kind of consultation with somebody and really fix a lot of the things early on. And then when you're like, hey, I think this thing's ready to go to main net, do an audit contest, and you'll find all the other stuff, essentially. That's the goal. Hi. Are there any standard protocols or platforms for holding these contests that you can recommend? Yeah, so I'm the CEO co-founder of Sherlock. Sherlock is one of the main ones, so I'm obviously very biased-founder of Sherlock Sherlock is one of the main ones so I'm obviously very biased but there's Sherlock there's code arena there is munified does them as well now there's a platform called cantina code Hawks hats so there's a few platforms out there thank you any other Any other questions? We have one here. Thank you. All this is very expensive. So what is your suggestion for small debt with very tight budgets? Thank you. Yeah. If you have a tight budget, I would say just try to keep your contracts as simple as possible. Every line of code is going to cost you money when it comes to the auditing phase. And you really want to pay per line of code. Essentially, you need to pay for the best people because those are the people who know how to hack contracts. And those people exist on the black hat side, like the bad guys. So you need to make sure you're paying for the best good guys as well to ensure that you find those vulnerabilities before you go to main net. So if you're kind of bootstrapping, just try to keep your code as small as possible, as simple as possible. Use other code that's already been audited if possible. And when you actually do do an audit, don't go for the cheapest provider because you really want to get that top talent, even if you have a small code base.",
"eventId": "devcon-7",
- "slot_start": 1731400800000,
- "slot_end": 1731406200000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1liuvnLXBUAB0kNGDh3VePfZNkfZ-ECHpzPYsSrv_d-M",
+ "slot_start": 1731400200000,
+ "slot_end": 1731402000000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Qlvu4fLzJTTaotuNmKf4QNZRg5u7Im3WjKq6D2kS0Vw",
"resources_slides": null,
"speakers": [
- "horsefacts"
+ "eleftherios-diakomichalis"
]
},
"vector": [
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -337812,11 +337114,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -337862,6 +337159,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -337883,6 +337181,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -337938,7 +337237,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -337993,6 +337291,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -338319,9 +337618,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
2,
0,
@@ -338341,46 +337640,29 @@
},
{
"session": {
- "id": "financial-nihilism-vs-foss-culture-the-battle-for-ethereums-soul",
- "sourceId": "SSXAMG",
- "title": "Financial Nihilism vs FOSS Culture: The Battle for Ethereum’s Soul",
- "description": "In recent years, the Ethereum ecosystem has witnessed a stark dichotomy: the rise of financial nihilism through memecoins and rampant speculation on one side, and the foundational principles of the FOSS (Free and Open Source Software) community, emphasising public goods, interdependence, and intrinsic rewards, on the other. \r\n\r\nThis talk will delve into the experiences of interacting with FOSS developers, shedding light on their views and concerns regarding Ethereum’s current trajectory.",
- "track": "Cypherpunk & Privacy",
+ "id": "financialization-in-games",
+ "sourceId": "EF3P9X",
+ "title": "Financialization in Games",
+ "description": "This talk will cover different financialization strategies we explored while building Project Mirage, and our lessons and learnings throughout the journey.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
"type": "Talk",
- "expertise": "Beginner",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Values",
- "FOSS",
- "Decentralization",
- "culture",
- "Decentralization",
- "FOSS",
- "Values"
- ],
"keywords": [
- "Culture"
+ "n/a"
],
- "duration": 1584,
+ "tags": [],
"language": "en",
- "sources_swarmHash": "d2fa049d664484b158c36db2c05b9ff461267f4ee44787a45a7ba182dabe07fc",
- "sources_youtubeId": "sNPxhnznfEA",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673336483a168eb535d564de.vtt",
- "transcript_text": " Hey everybody, great to see you all here. Thanks for coming out. I'm Jack Sanford. I'm the CEO and co-founder of Sherlock. Sherlock is one of the largest audit contest providers in the space. And today we're going to talk a little bit about the most common bugs found in audit contests. So if you're a protocol developer or if you want to become a protocol developer one day, you are going to be ahead of 90% of other protocol developers just by being aware of these 10 common bugs. So just a quick intro on audit contests and why you should care. Audit contests have become and are becoming one of the most popular ways to secure smart contract code before deploying a protocol to mainnet. There's been 625 audit contests run. The most have happened this year of any year. So it's really taking off 36,000 vulnerabilities found. 36 million in prizes have been paid out to thousands, tens of thousands of security experts, people who are learning to be security experts, all from finding bugs in these audit contests. And as you can see, the biggest teams in the space are using audit contests. All of these teams have done an audit contest this year in order to secure their code. So what is an audit contest? Essentially, the goal is to find bugs in code, usually critical bugs, bugs that are going to cause losses for users on mainnet. You start with a pot of money. You say, hey, here's 100k. Or in some cases, here's a million dollars. And we're going to pay people based on the bugs that they find. And anybody can participate. So it's a really great way to onboard to crypto, really great way to onboard to Web3 security, participating in audit contests. And depending on the severity of the bugs you find, so if they're critical severity, you're going to get paid more for them. If they're super unique and other people don't find them, you're going to get paid more for that. And if you find, you know, three of the four bugs that are in that protocol during that audit contest, you're going to get paid a lot of money for that. So really cool thing. And we're going to rip through super quickly the top 10 vulnerabilities that are found in audit contests these days. So number one, first depositor inflation attack in ERC4626 vaults. This is a super famous attack, really annoying because anytime you deploy a new vault on a blockchain, you're essentially exposed to this attack because the person who puts in the first deposit can essentially put in such a tiny deposit that it causes sort of a rounding issue and then all the deposits after that are a little bit messed up and the first depositor can steal funds that way and kind of DOS the vault. Second one, using transfer instead of safe transfer. So just using the transfer function in Solidity doesn't actually check the success or failure of a transfer, and it can also allow for really bad things like reentrancy with non-standard tokens such as USDT. Number three, missing validation and admin checks. So let's say you only want the owner of a contract to call a function or someone on a whitelist to call a function. A lot of times there's so many functions you just forget one, essentially, or you forget to check for something that you meant to check for. And that's what auditors are here for, and they're really good at finding that stuff. So this happens more often than you'd think. Okay, missing check for active L2 sequencer. So essentially, if you are deploying a protocol on top of an L2, like arbitrum or optimism, sometimes the sequencer goes down. Not very often, but it could happen in the future, and it could happen for long periods of time. And if you're a derivatives protocol or something where real-time information is super important, malicious actors can take advantage of stale prices because of the sequencer being down. Number five, the classic reentrancy, very first major vulnerability ever in Ethereum, the DAO hack. Basically, there are certain functions where essentially you can continue the execution outside of the function and call that very same function again and this can cause all kinds of problems there's a bunch of different like surface area for what these vulnerabilities can do but i'm sure a lot of you have heard of reentrancy already beyond transfer rebasing tokens so if you want your protocol to be able to handle any token out there, or even a pretty general set of tokens, a lot of them are non-standard. A lot of them don't conform to, you know, things that you would think that they conform to. And so smart contracts can get completely DOSed or funds can be lost because of these tokens having non-standard behavior with your functions. So rounding precision loss issues, this one has become really famous in the last 12 months, even if something is off by a couple of way or to the 18th, 17th decimal place, you can have major issues because of the way that solidity essentially, or the EVM essentially doesn't have floating point arithmetic. So it truncates things it rounds things a little bit and that can cause a lot of issues hitting the last three really quickly here using spot price instead of TWAP and Uniswap so this is something that I think we've all seen price manipulation attacks where someone basically inflates the value of a certain currency in a Uniswap pool for even one block and then does some attack using a flash loan and then it goes back down. So that one is really common, less common these days, thankfully. Incorrect implementation of upgradability. So essentially you want your contracts to be able to be upgraded, and it turns out you hard-coded something in an initializer, you hard-coded something in the constructor, and you can't actually upgrade your contracts, and you only find that out later. So that's kind of annoying, but not too big of a deal unless the initial deployment of your contracts is super critical. Last one, no slippage check in custom vaults and pools. So ERC4626 is great. Use, you know, standards whenever you can when you're developing in Solidity, because if you have non-standard pools, you can actually have your user sign up to get a trade done at one price, and then at the very next block or the very next execution, that price is completely different, and it can be off by a massive amount of percentage points. So your users can get really into trouble if you don't have slippage checks on your functions there. So that's the whole talk. If you're looking to become a protocol developer, check on these 10 things before you send your protocol to audits, and you'll be ahead of 90% of the other developers out there. Thank you, Jack. I see a question over there. When would you do an audit contest? Would it be like after you've done an audit or before you do your first audit or instead of a regular audit? What's the goal there? Yeah, it's a great question. If you can do multiple audits, I would normally say do the audit contest last because you get 300 people. It's a little bit, there's more operational complexity with it because you have to deal with 300 people. You know, Sherlock and others will deduplicate the issues for you. So if you can do a traditional audit or two before that, that's even better because you get to have kind of consultation with somebody and really fix a lot of the things early on. And then when you're like, hey, I think this thing's ready to go to main net, do an audit contest, and you'll find all the other stuff, essentially. That's the goal. Hi. Are there any standard protocols or platforms for holding these contests that you can recommend? Yeah, so I'm the CEO co-founder of Sherlock. Sherlock is one of the main ones, so I'm obviously very biased-founder of Sherlock Sherlock is one of the main ones so I'm obviously very biased but there's Sherlock there's code arena there is munified does them as well now there's a platform called cantina code Hawks hats so there's a few platforms out there thank you any other Any other questions? We have one here. Thank you. All this is very expensive. So what is your suggestion for small debt with very tight budgets? Thank you. Yeah. If you have a tight budget, I would say just try to keep your contracts as simple as possible. Every line of code is going to cost you money when it comes to the auditing phase. And you really want to pay per line of code. Essentially, you need to pay for the best people because those are the people who know how to hack contracts. And those people exist on the black hat side, like the bad guys. So you need to make sure you're paying for the best good guys as well to ensure that you find those vulnerabilities before you go to main net. So if you're kind of bootstrapping, just try to keep your code as small as possible, as simple as possible. Use other code that's already been audited if possible. And when you actually do do an audit, don't go for the cheapest provider because you really want to get that top talent, even if you have a small code base.",
- "eventId": "devcon-7",
- "slot_start": 1731400200000,
- "slot_end": 1731402000000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1Qlvu4fLzJTTaotuNmKf4QNZRg5u7Im3WjKq6D2kS0Vw",
- "resources_slides": null,
"speakers": [
- "eleftherios-diakomichalis"
- ]
+ "y77cao"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731579300000,
+ "slot_end": 1731580800000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/15r4rPTnKvKjpyxmg1BaFjdTPs2MB_Up2KIg320EKBjc"
},
"vector": [
0,
@@ -338388,7 +337670,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -338396,6 +337677,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -339237,7 +338519,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -339259,7 +338540,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -339370,7 +338650,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -339469,13 +338748,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -339698,7 +338970,14 @@
0,
0,
0,
- 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
0,
2,
0,
@@ -339718,29 +338997,25 @@
},
{
"session": {
- "id": "financialization-in-games",
- "sourceId": "EF3P9X",
- "title": "Financialization in Games",
- "description": "This talk will cover different financialization strategies we explored while building Project Mirage, and our lessons and learnings throughout the journey.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "find-yourself-on-the-mat",
+ "sourceId": "PYKTTA",
+ "title": "Find Yourself on the Mat",
+ "description": "By master Aoei \r\n- Self-tune\r\n- Find yourself along the journey with Oracle Cards\r\n - Gentle yoga flow & Stretching for Office Syndrome\r\n \r\nNov 12 16:45 - 17:30",
+ "track": "Entertainment",
+ "type": "Mixed Formats",
+ "expertise": "Beginner",
+ "audience": "Hobby",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "n/a"
- ],
+ "keywords": [],
"tags": [],
"language": "en",
- "speakers": [
- "y77cao"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731580800000,
- "slot_end": 1731582300000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/15r4rPTnKvKjpyxmg1BaFjdTPs2MB_Up2KIg320EKBjc"
+ "slot_start": 1731404700000,
+ "slot_end": 1731407400000,
+ "slot_roomId": "decompression-room",
+ "resources_presentation": "https://docs.google.com/presentation/d/1TFFR57Pxj41MY1aoKmiTItEaSPtPRaK4-BbRLFZTnQQ"
},
"vector": [
0,
@@ -339752,9 +339027,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -340090,7 +339362,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -341056,7 +340327,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -341069,6 +340339,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -341078,36 +340350,56 @@
},
{
"session": {
- "id": "find-yourself-on-the-mat",
- "sourceId": "PYKTTA",
- "title": "Find Yourself on the Mat",
- "description": "By master Aoei \r\n- Self-tune\r\n- Find yourself along the journey with Oracle Cards\r\n - Gentle yoga flow & Stretching for Office Syndrome\r\n \r\nNov 12 16:45 - 17:30",
- "track": "Entertainment",
- "type": "Mixed Formats",
+ "id": "finding-bugs-42-tips-from-4-security-researchers",
+ "sourceId": "AZNENK",
+ "title": "Finding Bugs: 42 Tips from 4 Security Researchers",
+ "description": "Billions of dollars are at risk, and protocols spend millions on security through audits and bug bounties. Have you ever wondered how you can become a top security researcher securing these billions?\r\n\r\nIn this workshop, 4 recognized security researchers share their experiences on smart contract security with practical tools & techniques to find & report vulnerabilities. Security researchers, even aspirational ones, can take away some key advice to improve their smart contract security skills.",
+ "track": "Security",
+ "type": "Workshop",
"expertise": "Beginner",
- "audience": "Hobby",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "tags": [
+ "Security",
+ "Auditing",
+ "Bug",
+ "Bounties",
+ "smart",
+ "contracts",
+ "Auditing",
+ "Bounties",
+ "Bug",
+ "Security"
+ ],
+ "keywords": [
+ "Education",
+ "Hacks",
+ "Smart Contract Security"
+ ],
+ "duration": 5654,
"language": "en",
- "speakers": [],
+ "sources_swarmHash": "5115b9b314e63c202aea765f7fc8025db430ff8d7f370ddddc28e16273af4e24",
+ "sources_youtubeId": "8d2UuzEBVdM",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731404700000,
- "slot_end": 1731407400000,
- "slot_roomId": "decompression-room",
- "resources_presentation": "https://docs.google.com/presentation/d/1TFFR57Pxj41MY1aoKmiTItEaSPtPRaK4-BbRLFZTnQQ"
+ "slot_start": 1731465900000,
+ "slot_end": 1731471300000,
+ "slot_roomId": "classroom-b",
+ "resources_presentation": "https://docs.google.com/presentation/d/1HZSm9H-PuHEKe3mrj7Wl9hDODP3kP9iQMoLjxXQ81Iw",
+ "resources_slides": null,
+ "speakers": [
+ "0xrajeev",
+ "joran-honig",
+ "nat-chin",
+ "tincho"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -341356,6 +340648,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -341379,6 +340672,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -341453,6 +340747,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -341853,6 +341149,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -342004,6 +341301,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -342108,6 +341406,9 @@
0,
0,
0,
+ 2,
+ 2,
+ 2,
0,
0,
0,
@@ -342122,6 +341423,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -342410,8 +341712,7 @@
0,
0,
0,
- 0,
- 0,
+ 2,
0,
0,
2,
@@ -342423,9 +341724,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -342434,61 +341732,43 @@
},
{
"session": {
- "id": "finding-bugs-42-tips-from-4-security-researchers",
- "sourceId": "AZNENK",
- "title": "Finding Bugs: 42 Tips from 4 Security Researchers",
- "description": "Billions of dollars are at risk, and protocols spend millions on security through audits and bug bounties. Have you ever wondered how you can become a top security researcher securing these billions?\r\n\r\nIn this workshop, 4 recognized security researchers share their experiences on smart contract security with practical tools & techniques to find & report vulnerabilities. Security researchers, even aspirational ones, can take away some key advice to improve their smart contract security skills.",
- "track": "Security",
- "type": "Workshop",
+ "id": "finding-rough-consensus-on-issuance",
+ "sourceId": "GSKJK8",
+ "title": "Finding rough consensus on issuance",
+ "description": "lido and ef researchers agree on far more than people think. this talk is an attempt to synthesize and explain my take on the big picture as simply as possible with plenty of humour.",
+ "track": "Core Protocol",
+ "type": "Talk",
"expertise": "Beginner",
- "audience": "Research",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Security",
- "Auditing",
- "Bug",
- "Bounties",
- "smart",
- "contracts",
- "Auditing",
- "Bounties",
- "Bug",
- "Security"
- ],
"keywords": [
- "Education",
- "Hacks",
- "Smart Contract Security"
+ "Issuance",
+ "Lido",
+ "Ethereum"
+ ],
+ "tags": [
+ "ethereum",
+ "Economics",
+ "Ethereum Roadmap",
+ "Politics"
],
- "duration": 5654,
"language": "en",
- "sources_swarmHash": "5115b9b314e63c202aea765f7fc8025db430ff8d7f370ddddc28e16273af4e24",
- "sources_youtubeId": "8d2UuzEBVdM",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731465900000,
- "slot_end": 1731471300000,
- "slot_roomId": "classroom-b",
- "resources_presentation": "https://docs.google.com/presentation/d/1HZSm9H-PuHEKe3mrj7Wl9hDODP3kP9iQMoLjxXQ81Iw",
- "resources_slides": null,
"speakers": [
- "0xrajeev",
- "joran-honig",
- "nat-chin",
- "tincho"
- ]
+ "sacha"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731555000000,
+ "slot_end": 1731556800000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1UZfs00-12fFWsIVRmhuoFq4kD-ulyhRRnI5VXPFmdeQ"
},
"vector": [
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -342732,7 +342012,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -342757,7 +342036,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -342832,11 +342110,10 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -343236,7 +342513,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -343272,6 +342548,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -343388,7 +342665,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -343429,6 +342705,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -343494,9 +342771,6 @@
0,
0,
0,
- 2,
- 2,
- 2,
0,
0,
0,
@@ -343511,7 +342785,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -343547,6 +342820,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -343573,6 +342847,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -343799,7 +343074,6 @@
0,
0,
0,
- 2,
0,
0,
2,
@@ -343809,6 +343083,9 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
0,
0,
0,
@@ -343819,43 +343096,46 @@
},
{
"session": {
- "id": "finding-rough-consensus-on-issuance",
- "sourceId": "GSKJK8",
- "title": "Finding rough consensus on issuance",
- "description": "lido and ef researchers agree on far more than people think. this talk is an attempt to synthesize and explain my take on the big picture as simply as possible with plenty of humour.",
- "track": "Core Protocol",
+ "id": "finding-your-place-in-crypto",
+ "sourceId": "CCVGE8",
+ "title": "Finding your place in crypto",
+ "description": "The crypto and Ethereum space can be a confusing place to navigate. It's important for us to remember that it's normal to sometimes feel like an impostor, not yet in the right place or that everyone else has their shit together. What matters more is how we deal with it, find the courage to form real connections, be kind to each other and ourselves.\r\nHere some frameworks and helpful personal insights to deal with this and truly enjoy the rollercoaster journey.",
+ "track": "Coordination",
"type": "Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Issuance",
- "Lido",
- "Ethereum"
+ "Personal",
+ "Human",
+ "Purpose"
],
"tags": [
- "ethereum",
- "Economics",
- "Ethereum Roadmap",
- "Politics"
+ "Governance",
+ "Decentralization",
+ "MEV",
+ "fairness",
+ "Coordination",
+ "Governance",
+ "Social"
],
"language": "en",
"speakers": [
- "sacha"
+ "chris",
+ "davide-rezzoli"
],
"eventId": "devcon-7",
- "slot_start": 1731555000000,
- "slot_end": 1731556800000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1UZfs00-12fFWsIVRmhuoFq4kD-ulyhRRnI5VXPFmdeQ"
+ "slot_start": 1731582600000,
+ "slot_end": 1731583800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/12xOmjbuWiCGoJo_Bx-KMT5zB8_88W6kmYHfhx1CzVcA"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -343863,6 +343143,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -344202,6 +343483,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -344601,6 +343883,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -344638,13 +343921,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -344701,11 +343977,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -344758,6 +344036,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -344782,6 +344061,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -344795,7 +344075,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -344911,7 +344190,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -345173,12 +344451,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0
@@ -345186,45 +344464,54 @@
},
{
"session": {
- "id": "finding-your-place-in-crypto",
- "sourceId": "CCVGE8",
- "title": "Finding your place in crypto",
- "description": "The crypto and Ethereum space can be a confusing place to navigate. It's important for us to remember that it's normal to sometimes feel like an impostor, not yet in the right place or that everyone else has their shit together. What matters more is how we deal with it, find the courage to form real connections, be kind to each other and ourselves.\r\nHere some frameworks and helpful personal insights to deal with this and truly enjoy the rollercoaster journey.",
- "track": "Coordination",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "",
+ "id": "firefly-build-your-own-hardware-wallet",
+ "sourceId": "LMZKZS",
+ "title": "Firefly - Build your own hardware wallet",
+ "description": "Build your own Firefly hardware wallet and write your first custom firmware in a short interactive session. All parts provided, just bring a laptop and USB-C cable.",
+ "track": "Developer Experience",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Personal",
- "Human",
- "Purpose"
- ],
"tags": [
- "Governance",
- "Decentralization",
- "MEV",
- "fairness",
- "Coordination",
- "Governance",
- "Social"
+ "DevEx",
+ "Hacks",
+ "Hardware wallets",
+ "arduino",
+ "DevEx",
+ "Hacks",
+ "Hardware wallets"
],
- "language": "en",
- "speakers": [
- "chris",
- "davide-rezzoli"
+ "keywords": [
+ "DIY",
+ "Arduino"
],
+ "duration": 564,
+ "language": "en",
+ "sources_swarmHash": "22e79a1778a0d016c579c6d3bff0ed86601dc90b1a2f896324503482136f2c30",
+ "sources_youtubeId": "NWdMDKMZdpQ",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343ffe9dbb7a90e1fa7007.vtt",
+ "transcript_text": " So a lot of you probably know me from, my slides are excellent, most of you probably know me from Ethers.js, but today I'll be talking to you about Firefly, our new exciting hardware wallet that we want to get in the hands of everyone. So keep an eye on my time. I see all the things. Okay, so what do we have? So what is Firefly? So Firefly, it's an open source firmware, open hardware, hardware wallet. It's going to be cost effective. Hopefully everyone will get them for free. We have like 126 to give out today. So feel free to drop by after and grab one. And it's customizable. You can do whatever you want with it. If you want to start your own Firefly competitor and just take our hardware and our software, you can run with it. If you can produce this cheaper than us, we welcome you to. The goal is to get security in the hands of people everywhere, no matter what. And so if you have a more cost-effective or a better way to disseminate to a group of people we can't reach, we want that. So again, it's about making HarderWalt fun again. Whether you want to put a game on it, whether you want it to be like a little animated GIF thing, Pong. If you have a CryptoKitty you really like and you just want like a HarderWalt that's just dedicated to that CryptoKitty only forever, you can do it. So, assembly. Originally, this was going to be a, like, two-hour, like, assembly thing. So, if you want to build your own, you're starting your own empire for Firefly, you're trying to take us out, first thing you need is a crew. So, my parents and my wife over here, we got together, and in an evening, I mean, it took about an hour and a half. I think we made 200 Firefly. So, I mean, my parents aren't super technical and they can build these things. I actually have one here I was going to build on stage, but I think I will forgo that just because I'm running out of hands. So, things you need, you need basically a pile system, you need a pile of the panelized boards, so six fireflies come per board. This is all in a script in the repository. If you want a single PCB board, you can do it and just have one firefly per board. If you've got a crazy manufacturing facility and you want a kilometer square of these things, you can just type those numbers in and I mean power to you. So you have a pile for like your completed Fireflies, your displays, the cases, and that's really it. It just like clips together. Again it's designed to be nice and simple. We're trying to like reduce costs to make it easier to do what you want to do. Right so step one,, I guess I can just cover this. You deep handle it, it just snaps off, and there you go, there's your Firefly. Then you clip your little screen in, I'm not going to do that right now, again, lack of hands, and snaps in. It's like a snap fit, so it has a nice satisfying click once it all works. Okay, so that's assembling. Provisioning. So this is where you might, if you were trying to like compete with us, do your own thing. So we have a private key that we use to sign each device. So the device generates the private key for attestation on the device. It's never been on any computer ever. It also is why it takes like two minutes to provision a device sometimes. RSA is kind of crazy. You basically pick a bunch of random numbers, do some rudimentary math to make sure it's not obviously not co-prime. And then you burn that to the chip. And well, first it sends that to a signing server, which signs it. It's a bunch of like back and forth. But at the end of the day, you get like proof on the device, sorry, evidence on the device that it can use to prove that it's a genuine device. So if you're trying to build your own CryptoKitty empire that each CryptoKitty lives on a device, now the device can prove to the world.",
"eventId": "devcon-7",
- "slot_start": 1731582600000,
- "slot_end": 1731583800000,
+ "slot_start": 1731473400000,
+ "slot_end": 1731474000000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/12xOmjbuWiCGoJo_Bx-KMT5zB8_88W6kmYHfhx1CzVcA"
+ "resources_presentation": "https://docs.google.com/presentation/d/12mlEi-XhwS1335VqCql4XOq2MN1ZU6WJeQLvyAc-QHU",
+ "resources_slides": null,
+ "speakers": [
+ "richard-moore"
+ ]
},
"vector": [
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -345233,7 +344520,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -345549,6 +344835,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -345573,8 +344860,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -345976,7 +345261,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -346002,6 +345286,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -346070,13 +345355,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -346129,7 +345412,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -346154,7 +345436,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -346225,6 +345506,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -346311,6 +345593,7 @@
0,
0,
2,
+ 2,
0,
0,
0,
@@ -346534,13 +345817,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
- 0,
0,
0,
+ 2,
0,
0,
0,
@@ -346549,7 +345832,6 @@
0,
0,
0,
- 2,
0,
0,
0
@@ -346557,53 +345839,40 @@
},
{
"session": {
- "id": "firefly-build-your-own-hardware-wallet",
- "sourceId": "LMZKZS",
- "title": "Firefly - Build your own hardware wallet",
- "description": "Build your own Firefly hardware wallet and write your first custom firmware in a short interactive session. All parts provided, just bring a laptop and USB-C cable.",
- "track": "Developer Experience",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Developer",
+ "id": "folding-starks-with-the-mova-folding-scheme",
+ "sourceId": "J78CHZ",
+ "title": "Folding STARKs with the Mova folding scheme",
+ "description": "We will present a new folding scheme that is 5 to 10 times more efficient than Nova, and 2.5 to 4 times more efficient than Hypernova. We will then explain how to use the scheme so as to construct a folding scheme for STARK proofs.",
+ "track": "Applied Cryptography",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "tags": [
- "DevEx",
- "Hacks",
- "Hardware wallets",
- "arduino",
- "DevEx",
- "Hacks",
- "Hardware wallets"
- ],
"keywords": [
- "DIY",
- "Arduino"
+ "Folding",
+ "Post-Quantum"
+ ],
+ "tags": [
+ "ZKP",
+ "Zero-Knowledge",
+ "STARK",
+ "post-quantum",
+ "STARK",
+ "Zero-Knowledge",
+ "ZKP"
],
- "duration": 564,
"language": "en",
- "sources_swarmHash": "22e79a1778a0d016c579c6d3bff0ed86601dc90b1a2f896324503482136f2c30",
- "sources_youtubeId": "NWdMDKMZdpQ",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343ffe9dbb7a90e1fa7007.vtt",
- "transcript_text": " So a lot of you probably know me from, my slides are excellent, most of you probably know me from Ethers.js, but today I'll be talking to you about Firefly, our new exciting hardware wallet that we want to get in the hands of everyone. So keep an eye on my time. I see all the things. Okay, so what do we have? So what is Firefly? So Firefly, it's an open source firmware, open hardware, hardware wallet. It's going to be cost effective. Hopefully everyone will get them for free. We have like 126 to give out today. So feel free to drop by after and grab one. And it's customizable. You can do whatever you want with it. If you want to start your own Firefly competitor and just take our hardware and our software, you can run with it. If you can produce this cheaper than us, we welcome you to. The goal is to get security in the hands of people everywhere, no matter what. And so if you have a more cost-effective or a better way to disseminate to a group of people we can't reach, we want that. So again, it's about making HarderWalt fun again. Whether you want to put a game on it, whether you want it to be like a little animated GIF thing, Pong. If you have a CryptoKitty you really like and you just want like a HarderWalt that's just dedicated to that CryptoKitty only forever, you can do it. So, assembly. Originally, this was going to be a, like, two-hour, like, assembly thing. So, if you want to build your own, you're starting your own empire for Firefly, you're trying to take us out, first thing you need is a crew. So, my parents and my wife over here, we got together, and in an evening, I mean, it took about an hour and a half. I think we made 200 Firefly. So, I mean, my parents aren't super technical and they can build these things. I actually have one here I was going to build on stage, but I think I will forgo that just because I'm running out of hands. So, things you need, you need basically a pile system, you need a pile of the panelized boards, so six fireflies come per board. This is all in a script in the repository. If you want a single PCB board, you can do it and just have one firefly per board. If you've got a crazy manufacturing facility and you want a kilometer square of these things, you can just type those numbers in and I mean power to you. So you have a pile for like your completed Fireflies, your displays, the cases, and that's really it. It just like clips together. Again it's designed to be nice and simple. We're trying to like reduce costs to make it easier to do what you want to do. Right so step one,, I guess I can just cover this. You deep handle it, it just snaps off, and there you go, there's your Firefly. Then you clip your little screen in, I'm not going to do that right now, again, lack of hands, and snaps in. It's like a snap fit, so it has a nice satisfying click once it all works. Okay, so that's assembling. Provisioning. So this is where you might, if you were trying to like compete with us, do your own thing. So we have a private key that we use to sign each device. So the device generates the private key for attestation on the device. It's never been on any computer ever. It also is why it takes like two minutes to provision a device sometimes. RSA is kind of crazy. You basically pick a bunch of random numbers, do some rudimentary math to make sure it's not obviously not co-prime. And then you burn that to the chip. And well, first it sends that to a signing server, which signs it. It's a bunch of like back and forth. But at the end of the day, you get like proof on the device, sorry, evidence on the device that it can use to prove that it's a genuine device. So if you're trying to build your own CryptoKitty empire that each CryptoKitty lives on a device, now the device can prove to the world.",
- "eventId": "devcon-7",
- "slot_start": 1731473400000,
- "slot_end": 1731474000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/12mlEi-XhwS1335VqCql4XOq2MN1ZU6WJeQLvyAc-QHU",
- "resources_slides": null,
"speakers": [
- "richard-moore"
- ]
+ "albert-garreta"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731638700000,
+ "slot_end": 1731640500000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/190Nsmxqio3tQ_4Rk6RPoyEf0-2DbZVoOuYNvY9It1YM"
},
"vector": [
- 0,
- 0,
- 0,
- 6,
0,
0,
0,
@@ -346614,6 +345883,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -346929,7 +346199,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -346956,6 +346225,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -347364,6 +346634,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -347382,7 +346653,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -347427,6 +346697,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -347562,6 +346833,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -347603,7 +346875,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -347690,7 +346961,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -347913,11 +347183,10 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
+ 2,
0,
2,
0,
@@ -347930,43 +347199,40 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "folding-starks-with-the-mova-folding-scheme",
- "sourceId": "J78CHZ",
- "title": "Folding STARKs with the Mova folding scheme",
- "description": "We will present a new folding scheme that is 5 to 10 times more efficient than Nova, and 2.5 to 4 times more efficient than Hypernova. We will then explain how to use the scheme so as to construct a folding scheme for STARK proofs.",
- "track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Expert",
- "audience": "Research",
+ "id": "for-the-kingdom-mud-day-demo",
+ "sourceId": "FM3LCK",
+ "title": "For The Kingdom - MUD Day Demo",
+ "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nFor The Kingdom (https://forthekingdom.xyz/) is a web-based MMORPG featuring a player-driven economy and worldbuilding, empowering players to be anyone they want to be.\r\n\r\nThe game is fully onchain, and currently live on the Redstone Garnet Testnet, using the MUD framework.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Folding",
- "Post-Quantum"
+ "fully",
+ "onchain",
+ "game"
],
"tags": [
- "ZKP",
- "Zero-Knowledge",
- "STARK",
- "post-quantum",
- "STARK",
- "Zero-Knowledge",
- "ZKP"
+ "Autonomous World",
+ "Gaming"
],
"language": "en",
"speakers": [
- "albert-garreta"
+ "tuyen-dinh"
],
"eventId": "devcon-7",
- "slot_start": 1731638700000,
- "slot_end": 1731640500000,
+ "slot_start": 1731556800000,
+ "slot_end": 1731557100000,
"slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/190Nsmxqio3tQ_4Rk6RPoyEf0-2DbZVoOuYNvY9It1YM"
+ "resources_presentation": "https://docs.google.com/presentation/d/19JLbZ-yVksBM4TM3ftOIccuAC6UgKAKtM0nVGAdWdQ4"
},
"vector": [
0,
@@ -347979,9 +347245,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -348733,7 +347999,39 @@
0,
0,
0,
- 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -348797,6 +348095,13 @@
0,
0,
2,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -348932,7 +348237,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -349060,44 +348364,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -349281,11 +348547,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
2,
0,
@@ -349296,48 +348562,46 @@
0,
0,
0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "for-the-kingdom-mud-day-demo",
- "sourceId": "FM3LCK",
- "title": "For The Kingdom - MUD Day Demo",
- "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nFor The Kingdom (https://forthekingdom.xyz/) is a web-based MMORPG featuring a player-driven economy and worldbuilding, empowering players to be anyone they want to be.\r\n\r\nThe game is fully onchain, and currently live on the Redstone Garnet Testnet, using the MUD framework.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "id": "fork-choice-enforced-inclusion-lists-focil",
+ "sourceId": "CDTX78",
+ "title": "Fork-Choice enforced Inclusion Lists (FOCIL)",
+ "description": "A direct consequence of centralized block production is a deterioration of Ethereum's censorship resistance properties. In this talk, we introduce FOCIL, a simple committee-based design improving upon previous inclusion list and co-created block mechanisms. We present the benefits of (1) relying on a committee to address issues related to bribing/extortion attacks, and (2) having attesters enforce the IL as part of the block validity condition to prevent IL equivocation.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "fully",
- "onchain",
- "game"
+ "Censorship Resistance",
+ "Inclusion Lists",
+ "Mechanism Design"
],
"tags": [
- "Autonomous World",
- "Gaming"
+ "Design",
+ "mechanism"
],
"language": "en",
"speakers": [
- "tuyen-dinh"
+ "thomas-thiery"
],
"eventId": "devcon-7",
- "slot_start": 1731556800000,
- "slot_end": 1731557100000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/19JLbZ-yVksBM4TM3ftOIccuAC6UgKAKtM0nVGAdWdQ4"
+ "slot_start": 1731570000000,
+ "slot_end": 1731571800000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1MowR6E3eFzSs1jXPUxgTBxReXgDFk6pgjqMA7hnC7t8"
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -349346,7 +348610,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -350196,9 +349459,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
0,
0,
0,
@@ -350229,6 +349489,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -350424,6 +349685,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -350645,6 +349907,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -350655,9 +349918,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -350669,40 +349929,44 @@
},
{
"session": {
- "id": "fork-choice-enforced-inclusion-lists-focil",
- "sourceId": "CDTX78",
- "title": "Fork-Choice enforced Inclusion Lists (FOCIL)",
- "description": "A direct consequence of centralized block production is a deterioration of Ethereum's censorship resistance properties. In this talk, we introduce FOCIL, a simple committee-based design improving upon previous inclusion list and co-created block mechanisms. We present the benefits of (1) relying on a committee to address issues related to bribing/extortion attacks, and (2) having attesters enforce the IL as part of the block validity condition to prevent IL equivocation.",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "formal-verification-in-the-ethereum-protocol-current-status-and-future-directions",
+ "sourceId": "KQCGWV",
+ "title": "Formal Verification in the Ethereum Protocol: Current Status and Future Directions",
+ "description": "Vitalik believes \"ethereum's biggest technical risk probably is bugs in code, and anything that could significantly change the game on that would be amazing\". Formal verification is a key technology which many believe could significantly help. However, it has yet to see wide adoption for a variety of reasons. This panel will bring together formal verification experts working in blockchain to discuss the challenges faced in increasing the use of formal verification within the community.",
+ "track": "Security",
+ "type": "Panel",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Censorship Resistance",
- "Inclusion Lists",
- "Mechanism Design"
+ "model checking",
+ "theorem proving"
],
"tags": [
- "Design",
- "mechanism"
+ "Security",
+ "Formal Verification",
+ "Testing",
+ "proving",
+ "theorem",
+ "Formal Verification",
+ "Security",
+ "Testing"
],
"language": "en",
"speakers": [
- "thomas-thiery"
+ "david-pearce",
+ "igor-konnov",
+ "julian-sutherland",
+ "zoe-p"
],
"eventId": "devcon-7",
- "slot_start": 1731570000000,
- "slot_end": 1731571800000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1MowR6E3eFzSs1jXPUxgTBxReXgDFk6pgjqMA7hnC7t8"
+ "slot_start": 1731465900000,
+ "slot_end": 1731469500000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1v3H83g6kUyGEXtHlMSYEBQw6ksu6---QQw0rs5zcxM8"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -350755,6 +350019,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -350879,6 +350144,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -351054,14 +350320,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -351454,6 +350716,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -351567,6 +350830,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -351594,7 +350858,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -351650,6 +350913,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -351692,6 +350956,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -352016,7 +351281,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -352029,96 +351293,46 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "formal-verification-in-the-ethereum-protocol-current-status-and-future-directions",
- "sourceId": "KQCGWV",
- "title": "Formal Verification in the Ethereum Protocol: Current Status and Future Directions",
- "description": "Vitalik believes \"ethereum's biggest technical risk probably is bugs in code, and anything that could significantly change the game on that would be amazing\". Formal verification is a key technology which many believe could significantly help. However, it has yet to see wide adoption for a variety of reasons. This panel will bring together formal verification experts working in blockchain to discuss the challenges faced in increasing the use of formal verification within the community.",
- "track": "Security",
- "type": "Panel",
- "expertise": "Intermediate",
+ "id": "fossify-yourself-for-privacy-and-security",
+ "sourceId": "TW7QGF",
+ "title": "FOSSify yourself for privacy and security",
+ "description": "You will leave this workshop at least a bit more cypherpunk than when you came. The session will introduce FOSS stack of tools for all platforms. We will discuss free operating systems, GNU/Linux distros, GrapheneOS, secure communication, browsing, hardware options and secure environment for handling your crypto or Ethereum validators.\r\nThe workshop is interactive and open to anyone to participate. Join us to find free and open solutions to your problems or come to share your favorite foss tools!",
+ "track": "Cypherpunk & Privacy",
+ "type": "Workshop",
+ "expertise": "Beginner",
"audience": "Engineering",
"featured": false,
- "doNotRecord": false,
+ "doNotRecord": true,
"keywords": [
- "model checking",
- "theorem proving"
+ "free software",
+ "degoogle",
+ "self hosting"
],
"tags": [
+ "Privacy",
"Security",
- "Formal Verification",
- "Testing",
- "proving",
- "theorem",
- "Formal Verification",
- "Security",
- "Testing"
+ "self",
+ "hosting",
+ "Privacy",
+ "Security"
],
"language": "en",
"speakers": [
- "david-pearce",
- "igor-konnov",
- "julian-sutherland",
- "zoe-p"
+ "mario-havel"
],
"eventId": "devcon-7",
- "slot_start": 1731465900000,
- "slot_end": 1731469500000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1v3H83g6kUyGEXtHlMSYEBQw6ksu6---QQw0rs5zcxM8"
+ "slot_start": 1731553200000,
+ "slot_end": 1731558600000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/1PShw8A7XomH3DtlwmgLZcgMrPY11XvLp_EuNeSwghoQ"
},
"vector": [
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -352250,7 +351464,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -352424,12 +351637,11 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -352824,7 +352036,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -352871,6 +352082,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -352938,7 +352150,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -352987,6 +352198,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -353021,7 +352233,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -353065,7 +352276,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -353165,7 +352375,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -353214,6 +352423,54 @@
0,
0,
0,
+ 2,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -353385,12 +352642,13 @@
0,
0,
0,
- 2,
0,
0,
0,
2,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -353407,38 +352665,48 @@
},
{
"session": {
- "id": "fossify-yourself-for-privacy-and-security",
- "sourceId": "TW7QGF",
- "title": "FOSSify yourself for privacy and security",
- "description": "You will leave this workshop at least a bit more cypherpunk than when you came. The session will introduce FOSS stack of tools for all platforms. We will discuss free operating systems, GNU/Linux distros, GrapheneOS, secure communication, browsing, hardware options and secure environment for handling your crypto or Ethereum validators.\r\nThe workshop is interactive and open to anyone to participate. Join us to find free and open solutions to your problems or come to share your favorite foss tools!",
- "track": "Cypherpunk & Privacy",
- "type": "Workshop",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "id": "fraud-proofs-war",
+ "sourceId": "UTTXWB",
+ "title": "Fraud proofs war",
+ "description": "Fraud proof systems were originally envisioned to be able to protect a rollup with just a single honest challenger assumption. As it turns out, the matter is much more complex because of exhaustion attacks, a form of sybil attack where the attacker tries to win by economically outlasting the defenders. The talk discusses the tradeoffs in the proposed solutions to this form of attack by analyzing Arbitrum, Cartesi and Optimism fraud proof systems.",
+ "track": "Layer 2",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Research",
"featured": false,
- "doNotRecord": true,
- "keywords": [
- "free software",
- "degoogle",
- "self hosting"
- ],
+ "doNotRecord": false,
"tags": [
- "Privacy",
- "Security",
- "self",
- "hosting",
- "Privacy",
- "Security"
+ "Optimistic rollups",
+ "Challenge period",
+ "Mechanism design",
+ "fraud",
+ "proof",
+ "Challenge period",
+ "Mechanism design",
+ "Optimistic rollups"
],
- "language": "en",
- "speakers": [
- "mario-havel"
+ "keywords": [
+ "Fraud",
+ "proofs"
],
+ "duration": 2519,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "tyouXHiQUmY",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732187c80d989c5b7d4fba3.vtt",
+ "transcript_text": " Hey, everybody. I was shocked by the evidence uncovered by the House Judiciary Committee that a group of companies organized a systematic illegal boycott against X. It is just wrong, and that is why we are taking action. Today, we filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. We filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. These organizations targeted our company and you, our users. The evidence and facts are on our side. They conspired to boycott X, which threatens our ability to thrive in the future. That puts your global town square, the one place that you can express yourself freely and openly, at long-term risk. People are hurt when the marketplace of ideas is constricted. No small group of people should be able to monopolize what gets monetized. This group is no match for the power of our users. All of you, the very same users that have driven usage of X to all-time highs. I joined X because I believe in the power of the global town square. It's users like you, people of all backgrounds and opinions, who make X indispensable. You deserve an open platform where your views can be expressed without restriction and without fear. To all of you who have been part of this transformative journey that we're on, thank you. Rest assured, X has never been more committed to innovating and expanding all of our global town square. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.",
"eventId": "devcon-7",
- "slot_start": 1731553200000,
- "slot_end": 1731558600000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/1PShw8A7XomH3DtlwmgLZcgMrPY11XvLp_EuNeSwghoQ"
+ "slot_start": 1731468600000,
+ "slot_end": 1731470400000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ft-eFG4MqCEgA32GW7jQmKsNVc9dmE6ItmC7m8A1nFs",
+ "resources_slides": null,
+ "speakers": [
+ "luca-donno"
+ ]
},
"vector": [
0,
@@ -353446,12 +352714,9 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -353746,7 +353011,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -353802,6 +353066,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -354193,7 +353458,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -354201,6 +353465,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -354261,6 +353526,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -354309,7 +353575,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -354417,6 +353682,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -354770,54 +354036,44 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "fraud-proofs-war",
- "sourceId": "UTTXWB",
- "title": "Fraud proofs war",
- "description": "Fraud proof systems were originally envisioned to be able to protect a rollup with just a single honest challenger assumption. As it turns out, the matter is much more complex because of exhaustion attacks, a form of sybil attack where the attacker tries to win by economically outlasting the defenders. The talk discusses the tradeoffs in the proposed solutions to this form of attack by analyzing Arbitrum, Cartesi and Optimism fraud proof systems.",
- "track": "Layer 2",
+ "id": "from-auctions-to-zk-an-educational-tour-of-mpc-tools",
+ "sourceId": "7TRTQW",
+ "title": "From Auctions to ZK: An Educational Tour of MPC Tools",
+ "description": "Ethereum made a significant contribution to the Cypherpunk agenda by removing central points of trust, allowing us to gain accountability, yet losing us any semblance of privacy that we had. There is hope at hand for privacy, but hope, in this case, is rather technical.\r\nThis talk aims to bring you up to scratch on privacy preserving tools while discussing S{N,T}ARKS, TEEs, FHE, how MPC elevates them in a decentralized setting, and highlighting their use from Auctions to ZK, from the 90s til now.",
+ "track": "Cypherpunk & Privacy",
"type": "Talk",
- "expertise": "Expert",
- "audience": "Research",
+ "expertise": "Intermediate",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Optimistic rollups",
- "Challenge period",
- "Mechanism design",
- "fraud",
- "proof",
- "Challenge period",
- "Mechanism design",
- "Optimistic rollups"
- ],
"keywords": [
- "Fraud",
- "proofs"
+ "Confidential",
+ "computing"
+ ],
+ "tags": [
+ "Zero-Knowledge",
+ "MPC",
+ "Homomorphic Encryption",
+ "confidentiality",
+ "computation",
+ "Homomorphic Encryption",
+ "MPC",
+ "Zero-Knowledge"
],
- "duration": 2519,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "tyouXHiQUmY",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732187c80d989c5b7d4fba3.vtt",
- "transcript_text": " Hey, everybody. I was shocked by the evidence uncovered by the House Judiciary Committee that a group of companies organized a systematic illegal boycott against X. It is just wrong, and that is why we are taking action. Today, we filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. We filed an antitrust lawsuit against the Global Alliance for Responsible Media, four of its key members, and the World Federation of Advertisers. These organizations targeted our company and you, our users. The evidence and facts are on our side. They conspired to boycott X, which threatens our ability to thrive in the future. That puts your global town square, the one place that you can express yourself freely and openly, at long-term risk. People are hurt when the marketplace of ideas is constricted. No small group of people should be able to monopolize what gets monetized. This group is no match for the power of our users. All of you, the very same users that have driven usage of X to all-time highs. I joined X because I believe in the power of the global town square. It's users like you, people of all backgrounds and opinions, who make X indispensable. You deserve an open platform where your views can be expressed without restriction and without fear. To all of you who have been part of this transformative journey that we're on, thank you. Rest assured, X has never been more committed to innovating and expanding all of our global town square. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.",
- "eventId": "devcon-7",
- "slot_start": 1731468600000,
- "slot_end": 1731470400000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1ft-eFG4MqCEgA32GW7jQmKsNVc9dmE6ItmC7m8A1nFs",
- "resources_slides": null,
"speakers": [
- "luca-donno"
- ]
+ "aisling-connolly"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731491400000,
+ "slot_end": 1731493200000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1VLWGFuzmpGa1l5aa_6_T3lRO-nTsPDh5IXDg9sFoZM8"
},
"vector": [
0,
@@ -354825,8 +354081,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -354953,6 +354207,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -355178,7 +354433,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -355579,11 +354833,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -355640,7 +354894,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -355661,6 +354914,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -355796,7 +355051,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -356132,16 +355386,15 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
- 0,
- 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -356155,41 +355408,45 @@
},
{
"session": {
- "id": "from-auctions-to-zk-an-educational-tour-of-mpc-tools",
- "sourceId": "7TRTQW",
- "title": "From Auctions to ZK: An Educational Tour of MPC Tools",
- "description": "Ethereum made a significant contribution to the Cypherpunk agenda by removing central points of trust, allowing us to gain accountability, yet losing us any semblance of privacy that we had. There is hope at hand for privacy, but hope, in this case, is rather technical.\r\nThis talk aims to bring you up to scratch on privacy preserving tools while discussing S{N,T}ARKS, TEEs, FHE, how MPC elevates them in a decentralized setting, and highlighting their use from Auctions to ZK, from the 90s til now.",
- "track": "Cypherpunk & Privacy",
+ "id": "from-bottlenecks-to-breakthroughs-optimizing-zkevm-provers",
+ "sourceId": "LT8BTE",
+ "title": "From Bottlenecks to Breakthroughs: Optimizing zkEVM Provers",
+ "description": "In this session, we introduce how we optimized zkEVM provers in production to significantly reduce prover costs, a major expense in running zkEVM. Topics include diagnosing zkEVM bottlenecks using CPU and memory profiling, leveraging DAGs for parallelization, and efficient memory management with a memory pool, fine-tuned garbage collection, and in-memory swapping for gigantic memory usage. These optimizations reduced zkEVM prover runtime by 75%, representing a substantial performance gain.",
+ "track": "Applied Cryptography",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Product",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Confidential",
- "computing"
+ "Performance",
+ "Optimization"
],
"tags": [
- "Zero-Knowledge",
- "MPC",
- "Homomorphic Encryption",
- "confidentiality",
- "computation",
- "Homomorphic Encryption",
- "MPC",
- "Zero-Knowledge"
+ "Layer 2s",
+ "ZK-EVMs",
+ "Open Source Software",
+ "optimization",
+ "Layer 2s",
+ "Open Source Software",
+ "ZK-EVMs"
],
"language": "en",
"speakers": [
- "aisling-connolly"
+ "leo-jeong"
],
"eventId": "devcon-7",
- "slot_start": 1731491400000,
- "slot_end": 1731493200000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1VLWGFuzmpGa1l5aa_6_T3lRO-nTsPDh5IXDg9sFoZM8"
+ "slot_start": 1731488400000,
+ "slot_end": 1731490200000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1uTR60xRfzUI21BwpSkQ39uJtzxKc0DLJd2BqZBQisTI"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -356322,7 +355579,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -356544,6 +355800,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -356954,7 +356211,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -357001,6 +356257,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -357031,15 +356288,8 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
+ 2,
0,
0,
0,
@@ -357502,16 +356752,15 @@
0,
0,
0,
- 0,
2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -357525,38 +356774,50 @@
},
{
"session": {
- "id": "from-bottlenecks-to-breakthroughs-optimizing-zkevm-provers",
- "sourceId": "LT8BTE",
- "title": "From Bottlenecks to Breakthroughs: Optimizing zkEVM Provers",
- "description": "In this session, we introduce how we optimized zkEVM provers in production to significantly reduce prover costs, a major expense in running zkEVM. Topics include diagnosing zkEVM bottlenecks using CPU and memory profiling, leveraging DAGs for parallelization, and efficient memory management with a memory pool, fine-tuned garbage collection, and in-memory swapping for gigantic memory usage. These optimizations reduced zkEVM prover runtime by 75%, representing a substantial performance gain.",
- "track": "Applied Cryptography",
+ "id": "from-concept-to-reality-the-triumph-of-blockchain-in-vaccine-distribution",
+ "sourceId": "ZBC9ZM",
+ "title": "From Concept to Reality: The Triumph of Blockchain in Vaccine Distribution",
+ "description": "Join us for an inspiring session that explores the transformative power of blockchain in vaccine supply chains. Learn how we achieved country-wide deployments in Bangladesh and Costa Rica, enhancing transparency, traceability, and efficiency. Discover the real-world challenges we overcame, the innovative solutions implemented, and the remarkable impact on public health logistics, setting new standards for supply chain management and ensuring the safe delivery of vaccines globally.",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "expertise": "Beginner",
+ "audience": "Business",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Performance",
- "Optimization"
- ],
"tags": [
- "Layer 2s",
- "ZK-EVMs",
- "Open Source Software",
- "optimization",
- "Layer 2s",
- "Open Source Software",
- "ZK-EVMs"
+ "Sustainability",
+ "Ethereum for Good",
+ "Public good",
+ "real-world",
+ "deployment",
+ "Ethereum for Good",
+ "Public good",
+ "Sustainability"
],
- "language": "en",
- "speakers": [
- "leo-jeong"
+ "keywords": [
+ "Real-World",
+ "Deployment"
],
+ "duration": 974,
+ "language": "en",
+ "sources_swarmHash": "a1313e35846a12d8159baaf1f5419c4b8846b08f315ac4c872079e5de0c97384",
+ "sources_youtubeId": "0dSz0CN6bI8",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333a7b3a168eb535edc345.vtt",
+ "transcript_text": " All right. Thank you for that. It's one of the last talks of the day. We don't have much time, so I hope it will be a good one for you guys. Yeah, so my name is Arun. I work with UNICEF. I'm the blockchain lead at the ventures team within the UNICEF Office of Innovation, and we are here to chat with one of our portfolio companies, Statwick, around the supply chain solution that they have worked on and the impact they are creating, along with a partner of ours on how to get these open source digital public goods funded. May I ask you guys to quickly introduce yourselves, starting with Mansi? focused on enhancing the transparency and efficiency in the global health public supply chain. What we essentially do is help stakeholders keep a track of all their transactions and give end-to-end visibility in the supply chains. Thank you, and thank you both for the invitation today. David Casey here, Director of Funding the Commons. Funding the Commons is a community and event series focused around exploring public goods funding mechanisms. And we do conferences, hackathons, open source developer residencies. We just completed one in Chiang Mai last month. And public goods funding experiments, so applied experiments using new mechanisms. So in case you're wondering what a UNICEF person is doing here, so we have been working with blockchain since 2015. We run something called the UNICEF Venture Fund, where we provide funding for early-stage startups, such as StatWig that Mansi is working for, and we are also interested in digital public goods. We are part of the Digital Public Goods Alliance, and that's how we got to know David. So hence, here I am. First question to Mansi. Could you please maybe talk a bit of the product around the vaccine supply chains, please? Yeah. So I think the problem, the challenge that we were looking at was twofold. So the first initial issue was around how these supply chains are fragmented and specifically in the healthcare systems, how they rely on siloed information which do not talk to each other. The other issue was also around product wastage in terms of expiry, counterfeiting and cold chain failures. So this was like the primary agenda that we wanted to solve firsthand and have a unified platform. So that is where we've built a solution called Vaccine Ledger, which typically ensures that every physical asset in the supply chain, we create a digital twin of that. And so from how that works is that from the time of procurement or from the point of manufacturing, and every time the product changes hands we basically record the journey of products as and how it is passing on so we help ensure that you know all these stakeholders are completely aware of where the product is in supply chain right now yeah and and we did we did also have like issues looking around how 30 percent of the global vaccines were wasted. And there was lack of information even within many organizations who were sending out products to various LMIC countries, but there was lack of visibility whether it's reaching the final beneficiaries or not. So it becomes very important and critical to ensure that the life-saving vaccines and medicines reach to those people, especially in the under-deserved areas. And that's how I think what we're trying to do is leverage blockchain and provide the whole data in real time for every stakeholder to make informed decision. That's fantastic. So blockchain here is, of course, used to track every vial of the vaccine, I think which adds a next layer of traceability and you know visibility which all the stakeholders get. And talking of stakeholders, where have you piloted the solution so far? Yeah, so we've had a couple of deployments. So we had it both on the private side also and on the public. So we did a couple of deployments in Costa Rica. We had partnership with IDB, Inter-American Development Bank, who actually opened doors for us to help track products within that market. So the major issue at hand was that once the manufacturers send the product, they only have visibility till Panama. And after which there's like complete lack of understanding of how is the product moving in the country. So we did make a deployment there. And even during COVID, we were able to like track a million doses of COVID-19 vaccines and also the end beneficiaries who were receiving it. And we did have another department, which",
"eventId": "devcon-7",
- "slot_start": 1731488400000,
- "slot_end": 1731490200000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1uTR60xRfzUI21BwpSkQ39uJtzxKc0DLJd2BqZBQisTI"
+ "slot_start": 1731409200000,
+ "slot_end": 1731410400000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1yuhgDizD0e2BcBSAmT-nwGyHIS4gNNqFjMZbvO34IPc",
+ "resources_slides": null,
+ "speakers": [
+ "david-casey",
+ "arun-maharajan",
+ "mansi"
+ ]
},
"vector": [
0,
@@ -357565,10 +356826,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -357644,6 +356901,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -357918,10 +357177,9 @@
0,
0,
0,
- 6,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -358377,7 +357635,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -358409,7 +357666,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -358422,6 +357678,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -358438,6 +357695,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -358494,6 +357752,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -358872,6 +358131,7 @@
0,
0,
0,
+ 0,
2,
0,
0,
@@ -358887,57 +358147,40 @@
0,
0,
0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "from-concept-to-reality-the-triumph-of-blockchain-in-vaccine-distribution",
- "sourceId": "ZBC9ZM",
- "title": "From Concept to Reality: The Triumph of Blockchain in Vaccine Distribution",
- "description": "Join us for an inspiring session that explores the transformative power of blockchain in vaccine supply chains. Learn how we achieved country-wide deployments in Bangladesh and Costa Rica, enhancing transparency, traceability, and efficiency. Discover the real-world challenges we overcame, the innovative solutions implemented, and the remarkable impact on public health logistics, setting new standards for supply chain management and ensuring the safe delivery of vaccines globally.",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Business",
+ "id": "from-mpc-wallets-to-smart-contract-accounts",
+ "sourceId": "XMTH8N",
+ "title": "From MPC Wallets to Smart Contract Accounts",
+ "description": "The proposal outlines a path for the mass adoption of smart contract accounts by using MPC wallet as a transitional solution. Users can start their web3 journey by using MPC wallets which can be done via social login. Later, users can turn the MPC wallets into smart contract wallets using EIP-7702, enhancing the user experience with feature-rich options while maintaining the security benefits of MPC wallets to protect the EOA private key.",
+ "track": "Usability",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Sustainability",
- "Ethereum for Good",
- "Public good",
- "real-world",
- "deployment",
- "Ethereum for Good",
- "Public good",
- "Sustainability"
- ],
"keywords": [
- "Real-World",
- "Deployment"
+ "EIP-7702"
+ ],
+ "tags": [
+ "MPC",
+ "Account Abstraction",
+ "eip-7702",
+ "Account Abstraction",
+ "MPC"
],
- "duration": 974,
"language": "en",
- "sources_swarmHash": "a1313e35846a12d8159baaf1f5419c4b8846b08f315ac4c872079e5de0c97384",
- "sources_youtubeId": "0dSz0CN6bI8",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333a7b3a168eb535edc345.vtt",
- "transcript_text": " All right. Thank you for that. It's one of the last talks of the day. We don't have much time, so I hope it will be a good one for you guys. Yeah, so my name is Arun. I work with UNICEF. I'm the blockchain lead at the ventures team within the UNICEF Office of Innovation, and we are here to chat with one of our portfolio companies, Statwick, around the supply chain solution that they have worked on and the impact they are creating, along with a partner of ours on how to get these open source digital public goods funded. May I ask you guys to quickly introduce yourselves, starting with Mansi? focused on enhancing the transparency and efficiency in the global health public supply chain. What we essentially do is help stakeholders keep a track of all their transactions and give end-to-end visibility in the supply chains. Thank you, and thank you both for the invitation today. David Casey here, Director of Funding the Commons. Funding the Commons is a community and event series focused around exploring public goods funding mechanisms. And we do conferences, hackathons, open source developer residencies. We just completed one in Chiang Mai last month. And public goods funding experiments, so applied experiments using new mechanisms. So in case you're wondering what a UNICEF person is doing here, so we have been working with blockchain since 2015. We run something called the UNICEF Venture Fund, where we provide funding for early-stage startups, such as StatWig that Mansi is working for, and we are also interested in digital public goods. We are part of the Digital Public Goods Alliance, and that's how we got to know David. So hence, here I am. First question to Mansi. Could you please maybe talk a bit of the product around the vaccine supply chains, please? Yeah. So I think the problem, the challenge that we were looking at was twofold. So the first initial issue was around how these supply chains are fragmented and specifically in the healthcare systems, how they rely on siloed information which do not talk to each other. The other issue was also around product wastage in terms of expiry, counterfeiting and cold chain failures. So this was like the primary agenda that we wanted to solve firsthand and have a unified platform. So that is where we've built a solution called Vaccine Ledger, which typically ensures that every physical asset in the supply chain, we create a digital twin of that. And so from how that works is that from the time of procurement or from the point of manufacturing, and every time the product changes hands we basically record the journey of products as and how it is passing on so we help ensure that you know all these stakeholders are completely aware of where the product is in supply chain right now yeah and and we did we did also have like issues looking around how 30 percent of the global vaccines were wasted. And there was lack of information even within many organizations who were sending out products to various LMIC countries, but there was lack of visibility whether it's reaching the final beneficiaries or not. So it becomes very important and critical to ensure that the life-saving vaccines and medicines reach to those people, especially in the under-deserved areas. And that's how I think what we're trying to do is leverage blockchain and provide the whole data in real time for every stakeholder to make informed decision. That's fantastic. So blockchain here is, of course, used to track every vial of the vaccine, I think which adds a next layer of traceability and you know visibility which all the stakeholders get. And talking of stakeholders, where have you piloted the solution so far? Yeah, so we've had a couple of deployments. So we had it both on the private side also and on the public. So we did a couple of deployments in Costa Rica. We had partnership with IDB, Inter-American Development Bank, who actually opened doors for us to help track products within that market. So the major issue at hand was that once the manufacturers send the product, they only have visibility till Panama. And after which there's like complete lack of understanding of how is the product moving in the country. So we did make a deployment there. And even during COVID, we were able to like track a million doses of COVID-19 vaccines and also the end beneficiaries who were receiving it. And we did have another department, which",
- "eventId": "devcon-7",
- "slot_start": 1731409200000,
- "slot_end": 1731410400000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1yuhgDizD0e2BcBSAmT-nwGyHIS4gNNqFjMZbvO34IPc",
- "resources_slides": null,
"speakers": [
- "david-casey",
- "arun-maharajan",
- "mansi"
- ]
+ "phuc-thai"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731559200000,
+ "slot_end": 1731559800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ZE8L3c1yymoZrVimyFHEaxXRlckYyGWHcRVxv5R5bzQ"
},
"vector": [
0,
@@ -358946,6 +358189,8 @@
0,
0,
0,
+ 0,
+ 0,
6,
0,
0,
@@ -359021,9 +358266,7 @@
0,
0,
0,
- 6,
0,
- 6,
0,
0,
0,
@@ -359740,6 +358983,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -359777,6 +359021,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -359801,8 +359046,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -359818,7 +359061,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -359875,7 +359117,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -360043,7 +359284,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -360253,9 +359493,10 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
- 2,
0,
0,
0,
@@ -360269,52 +359510,52 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "from-mpc-wallets-to-smart-contract-accounts",
- "sourceId": "XMTH8N",
- "title": "From MPC Wallets to Smart Contract Accounts",
- "description": "The proposal outlines a path for the mass adoption of smart contract accounts by using MPC wallet as a transitional solution. Users can start their web3 journey by using MPC wallets which can be done via social login. Later, users can turn the MPC wallets into smart contract wallets using EIP-7702, enhancing the user experience with feature-rich options while maintaining the security benefits of MPC wallets to protect the EOA private key.",
- "track": "Usability",
+ "id": "from-nanoseconds-to-decades-the-timescales-of-ethereum",
+ "sourceId": "CGTBC7",
+ "title": "From Nanoseconds to Decades: The Timescales of Ethereum",
+ "description": "Ethereum is an intricate machine with numerous gears meshing into each other. Some are tiny and spin at lightning speed, others barely move. In this short talk, we will embark on a brief journey through the various processes within Ethereum, examining how long they take -- from executing a single OP code to accepting an EIP.",
+ "track": "Core Protocol",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Product",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "EIP-7702"
+ "Fun",
+ "Data"
],
"tags": [
- "MPC",
- "Account Abstraction",
- "eip-7702",
- "Account Abstraction",
- "MPC"
+ "Core Protocol",
+ "data",
+ "fun",
+ "Core",
+ "Protocol"
],
"language": "en",
"speakers": [
- "phuc-thai"
+ "jannik-luhn"
],
"eventId": "devcon-7",
- "slot_start": 1731559200000,
- "slot_end": 1731559800000,
+ "slot_start": 1731469200000,
+ "slot_end": 1731469800000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1ZE8L3c1yymoZrVimyFHEaxXRlckYyGWHcRVxv5R5bzQ"
+ "resources_presentation": "https://docs.google.com/presentation/d/1Ry_A-NlHMHVJmRMfoIquVsBqvO4xh-ZsvcBax7Ji6fk"
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -361074,6 +360315,28 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -361109,7 +360372,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -361147,7 +360409,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -361339,6 +360600,22 @@
0,
0,
0,
+ 2,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -361371,6 +360648,22 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -361410,59 +360703,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -361626,7 +360866,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -361635,50 +360874,61 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "from-nanoseconds-to-decades-the-timescales-of-ethereum",
- "sourceId": "CGTBC7",
- "title": "From Nanoseconds to Decades: The Timescales of Ethereum",
- "description": "Ethereum is an intricate machine with numerous gears meshing into each other. Some are tiny and spin at lightning speed, others barely move. In this short talk, we will embark on a brief journey through the various processes within Ethereum, examining how long they take -- from executing a single OP code to accepting an EIP.",
- "track": "Core Protocol",
+ "id": "from-packets-to-privacy-understanding-and-evolving-network-security",
+ "sourceId": "XYRFXT",
+ "title": "From Packets to Privacy: Understanding and Evolving Network Security",
+ "description": "This talk will provide a comprehensive journey through the fundamentals of network communication, explore the workings and risks of Virtual Private Networks (VPNs), and dive into the world of Mixnets. We’ll discuss how decentralized Mixnets can offer privacy by default, potentially eliminating the need for traditional VPNs.",
+ "track": "Cypherpunk & Privacy",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Fun",
- "Data"
- ],
"tags": [
- "Core Protocol",
- "data",
- "fun",
- "Core",
- "Protocol"
+ "Privacy",
+ "Anonymity",
+ "Censorship Resistance",
+ "vpn",
+ "Anonymity",
+ "Censorship Resistance",
+ "Privacy"
],
- "language": "en",
- "speakers": [
- "jannik-luhn"
+ "keywords": [
+ "Mixnet",
+ "VPN"
],
+ "duration": 529,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "7FyShvrYnHk",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": "6734a0f89dbb7a90e1476ca9",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67349b569dbb7a90e11ec407.vtt",
+ "transcript_text": " On Twitter, you know I promised a joyful and uplifting presentation. I lied. This is going to be pretty pragmatic and realistic. I'm going to tell you about how to use Ethereum and specifically smart contracts to do something useful and interesting with privacy. So, a couple of key topics for today. Number one, let's press the magic button. We're having technical difficulties. So first item I want to talk about is the business case for privacy. And as soon as the clicker works, we will advance to the next slide, which it's not doing. It's not doing that. So anyway, I'm going to talk from a little bit of memory. So pretty much every business agreement comes down to something very simple. I've got money, you've got stuff, and I would like to exchange my money for your stuff under the terms of a business agreement. And the challenge with that is that for companies, they want that information to be private. How much money you have, how much stuff you have, what you're buying, where it's going, that's all like super secret, sensitive business information. Oh, it's working now. So business case for privacy. As I said, companies want to do very simple stuff, exchange money for stuff under the terms of an agreement with privacy. And blockchain is actually this incredible piece of infrastructure for doing this way more efficiently. So we can tokenize the money, we can tokenize the stuff, and we can turn all the business terms and conditions into a programmable set of rules that can be implemented very easily. To make this work, however, we need two kinds of privacy. Number one, we need privacy about the transfer of assets and payments. How much I'm paying you, what you're giving me, where it's going. That stuff needs to be private. But secondly, we also need privacy for the terms and conditions of our agreement. It's really important. If I can read the agreement between company A and company B and it says I'm going to buy 500 widgets at $10 a piece, I'm going to kind of give away all the information that you need to know anyway. So we need these two kinds of privacy. And in particular, pseudo-privacy or mixers or things like that aren't really good enough for businesses because a lot of companies do lots and lots of recurring business with each other, and eventually, if you do enough of these types of transactions, you're going to be traceable even in a public mixer environment, and most business assets are not fungible tokens. Money might be fungible, but the things that you're buying are often not fungible, and anything that's non-fungible becomes instantly traceable in a public environment. So it's really hard to design without leaking information, and that's some of the stuff that we've really been working on. Now, before I talk to you about how, I just want to take a second and talk about what is the value proposition? Why is this worth doing? And I want to share with you a very specific example, which is around the use of smart contracts for business automation. About five years ago, EY and Microsoft worked together to replace the procurement system for the Xbox video game network with a set of smart contracts. And the idea here was to replace an existing system which had a traditional ERP system, and it was sort of semi-automated. At the end of each month, they would look at all the transactions, and they would manually apply some of the rules that they had implemented between Microsoft and their 3,000-odd gaming suppliers. Well, it took, on average, in the old system, about 45 days to calculate how much they were owed and go through all the individual contracts and special rules. When we turn those into blockchain-based smart contracts, the beauty of these kind of smart contracts is they're basically scripts, right? It doesn't matter. As long as the rules that you and I have agreed upon are logical and clear, then I can automate them and they can run properly. And the result was that we basically took a process that used to take 45 days and we brought it down to about five minutes, right? That is a good improvement. And we did it for about half the cost of the existing system. So the value proposition of being able to take a complex business agreement and turn it into an automated smart contract is incredibly large. The problem that we had at the time was we didn't know how to do this under privacy on a public blockchain. Eventually, where we want to go to is this ability to put together tokenization with smart contracts and in a way that you can create a complete business model that's running on chain. In this picture, what we have is a very typical supply chain, right? Raw materials, they get manufactured, they get transported, they get put in a warehouse, they get sold to a customer, and then they get supported. Now, every single item in a traditional manufacturing supply chain we can represent as a token. Some of the things are fungible tokens, most of them are non-fungible tokens. Anything with a serial number becomes a non-fungible token. And so basically in this picture, stuff moves from left to right, and money moves from right to left, and a set of smart contracts governs this movement of the process away. And not only can we run the business process for about half the cost, but we can also run the supply chain much more efficiently. We think we can typically, if we move from traditional supply chain models to a tokenized supply chain model with all the rules of preventing double spend, you can actually cut maybe as much as 20% of the inventory from your supply chain and have the same service level. So in short, this is worth crazy amounts of money. Now, let's talk about a specific use case that we are implementing for clients and rolling out worldwide, and this is renewable energy. And I want to talk about why renewable energy is such an incredible use case and application and how we got there. I want to start with the roadmap for privacy that we are working on at EY. We've got two applications that we're building. I talked about two types of privacy that we are working on at EY. We've got two applications that we're building. I talked about two types of privacy that we want to do. One is privacy of moving stuff around, and the other is privacy of the terms and conditions of a business agreement. So for the privacy of tokenization and moving things around, we have created a Layer 2 ZK rollup called Nightfall. Nightfall allows you to move around fungible and non-fungible tokens. It's an EVM compatible layer two, so it actually can run on top of the main net. It can also run on top of, say, a layer two as a layer three. So Nightfall is for moving stuff around. Starlight is a transpiler that basically takes a Solidity Smart contract and turns it into a set of zero knowledge circuit. Our idea, our concept is to get each one of these pieces working independently and then bring them together so that you can have this full business to business kind of complex road map. Both of these, to be clear, are, although they are largely developed by EY, we have put them into the public domain. They are public domain, open source contributions to the Ethereum ecosystem. There are no proprietary gotchas here. There are no surprise, like, you know, special terms and conditions in the open source license. It is full public domain. We have relinquished all ownership to these assets. Thank you, sir. That is how much we love and believe in the Ethereum ecosystem. And we have been on this journey for a while, by the way. I know we're getting a lot of attention from the Noir program that's launched this week. I tell you that we started about the same time as the folks at Aztec, and most of our team is across town from them in London. And one of the things that delights me so much is to come to DevCon and see how much competition is now in the privacy space. I really believe that even if we lose in a competitive race with some of the other solutions, we win. But I'm not yet given up on losing. We have been on this journey for a while, even though the numbers didn't sort of look out correctly. We started in 2017. And here we are in 2024. We're on Nightfall version 4. Nightfall version 3, which is currently in production, is a ZK optimistic roll-up. ZK for privacy, optimism for finality. Nightfall version 4, which we showed off earlier this year and will be in production next year, is a ZK, ZK roll-up. So one ZK for privacy and one for instant finality. All right, let's talk about renewable energy and exactly how we implemented this. So the way that renewable energy contracts work, and the reason why they're such a good candidate for zero knowledge applications is that they are kind of complicated. And this is a simplified version. Very simply, you got a power buy. You got somebody, they got a factory, they want electricity, they want a lot of electricity, they're going to buy it from somebody. But maybe they're a large company, they have a good social responsibility plan, they have committed to become carbon neutral. So what power buyers do is they reach an agreement with a renewable energy seller, somebody who's got solar facilities, battery facilities, whatever it is that's renewable and fully green. Here's the problem. Electrons are fungible, right? You might want to have your locally produced organic artisanal electrons, but actually the way it works is you have to take what the power company is giving you. And so what happens is the power buyer basically buys electricity from the power company at whatever the market price is in their environment. The power company in turn buys power from a whole bunch of suppliers. Some of them are very green, some of them are not so green. The agreement exists between the renewable seller and the renewable buyer. And what the smart contract does is it basically keeps track of the market price that the power buyer paid to the electric company and the difference between that and the agreed upon price and then they settle up usually every month or so if one party owes the other. And there's usually complex terms and conditions like a commitment to buy a certain minimum amount of power in the grid or a certain maximum price that they have to pay. And the idea is that they are basically providing the incentive and enough financial value to the renewable provider to structure long-term investment. And these renewable energy contracts are incredibly important because a lot of these solar facilities, wind facilities, they could not be built without the advanced commitment of buyers like these kinds of factories or other companies that are committed to be carbon neutral. These advanced commitments that they make, they're often five or ten years at a certain price for a certain number of megawatts. These are incredibly important to guaranteeing the revenue that provides the investment funding to build these kinds of facilities. Right, so that's what the structure is. So a little bit like, you know, video game contracts with thresholds and minimums and rebates, renewable energy contracts can be quite complex. To build this renewable energy contract, we went through a multi-step process, which I want to explain. We started by just creating a Solidity smart contract without privacy that followed the terms and conditions that we wanted to implement. And once we had that working, we created a modified Solidity application, which we call a Solidity application. And all we did was mark up the variables and the logic that we want to be private. So we have a little guide on how to do this. And then we put that into the Starlight transpiler. And what that does is it spits out a zero-knowledge circuit, a whole application that you can run on-chain, which we call a ZAP, right, for a zero knowledge app. And please don't ask me who is in charge of our naming, but there's a lot of Zs in there. And so the idea here is to keep it very simple. And Starlight itself came out of a really important learning experience we had. So about three or four years ago, we tried to teach our research team, our PhD mathematicians, tried to sit down and teach our developers how to write zero knowledge circuits using tools like Socrates. It was a spectacular train wreck. Like, it just did not work at all. Our solidity developers were like, this is too difficult. I don't like this. I don't want to do this. And so we went back to the drawing board and we said, we need to find a way to make this much easier and much simpler, and you just should have to do some minor changes to a Solidity smart contract. And that's how we ended up with Starlight. So Starlight is really designed to be as easy as possible. It allows you to take a Solidity application that you know already works and turn it into a zero-knowledge application. You still have to think very carefully about how to design it in such a way that you're not going to leak really sensitive metadata. Because if you're not careful, you will accidentally end up leaking metadata. But the goal is to get to the point where anybody can do applications. As I said, it's public domain and open source. You can go and try it out yourself. There are currently about 100 companies worldwide that are designing and testing applications using Starlight. And in particular, we've been working very closely with the Central Bank of Brazil. We have about 60 or 70 banks in Brazil that are testing out Starlight-based applications. And for the last year, we've been working really hard to refine the Starlight application development process and tooling. Right now, where we are is that we are in a kind of a stateless environment. So the Starlight application receives data, it calculates the amounts owed, but it does not store anything on-chain, it doesn't store any commitments even off-chain, it's a stateless component, and transactions are relatively inexpensive, provided you deploy them on a layer two network. The future path is that we want to integrate Starlight with on-chain payment and with some level of off-chain stateful storage of things like the amount of electricity consumed and the amount of money paid so that you really have a proper continuous record of the entire set of business transactions. But that's the goal. As I said, we're following a kind of crawl, walk, run strategy, and the goal is to start and build things that are very pragmatic and useful to business users rather than try to bite off the whole thing at once. So we have fundamentally a bit of a different approach than, say, Aztec or some of the others who I think have a very ambitious and kind of complete approach. We welcome participation. Our content, it's public domain, it's open source. All of our tools are open and available, and we publish them on the EY blockchain site on GitHub. So that's really important to us. We have many, many contributors, but underpinning all of this is kind of a long-term commitment from EY to invest in privacy because we believe it is the one thing that enterprises need in order to get fully engaged with on-chain business and to give up this fixation that a lot of people have with private blockchains. Lastly, we are here. We have an impact booth. Our research team is here, and quite a few members of our engineering team as well. We would love to talk to you about how to help you make privacy-enabled applications that are regulatory compliant. They will not end you up in jail. I feel like I myself would not do very well in prison, so I don't want to go there. And then lastly, I'm ready to take a couple questions, but I also want to share with you my little QR code. It will take you to a website that will give you what we call a proof of Paul NFT, which is minted on the Polygon proof of stake blockchain, and we made a special one just for DevCon. So, am I on time? Have we got enough time for a couple minutes of questions? Yeah, we've got some time. We've got about six, seven minutes. Perfect. So, we've actually got a lot of questions, but feel free to ask some more on here. So, it looks like the top question here is, why did you build Nightfall rather than contribute to other open source ZK roll-ups? Well, at the time that we got started, there weren't any other open source ZK roll-ups. I mean, this was seven years ago. And by the way, almost all the ZK roll-ups that are out there are ZK for scaling, not ZK for privacy. And in fact, one of my frustrations was, you know, seven, eight years ago when we got started down this path, everyone's like, hey, we got to fix the scaling problem for Ethereum. And while I agree with that, and I'm really pleased with the progress that Ethereum has made on scaling, I think it's incredible. And the end of the day for business users, there's no scaling. The scaling problem is not a problem until you solve the privacy problem. Without privacy, no business user is going to touch Ethereum. And I want every business agreement in the future to be on Ethereum. Awesome. Well, how do you tokenize real-world assets without them being centralized? That's a great question. So I think, let's see here. I guess the quick answer is, I think for individual companies, those assets are going to be, if you're tokenizing your own assets, it is going to be, to a certain degree, centralized in your company. And this is kind of an issue that we've talked about a lot with other people, is in certain circumstances, there are some things where only one participant really knows the status of that asset. The only company that knows where your UPS or FedEx package is, is UPS or FedEx, right? And so you have to accept that. And one thing that is a really cool thing is there's a process, a well-accepted business process from the world of TradFi. It's called a SOC audit, right, which is a systems and organizations control. And what it is, is you have an independent organization come in and assess your reporting mechanism. And so in the cases where you can't have proper decentralization, you should have external auditing and testing to make it more reliable. And I think we have time for one more question. Can you talk about the Brazilian CBDC and how the experience is of using Starlight on Drex? And for my sake, can you explain what Drex is? Yes. So Brazil has a really cool, they've had some really cool thoughts about their CBDC. So as many of you may know, CBDCs are really struggling with acceptance and success because they don't offer a lot of value. The Brazilian Central Bank has taken note of that and they've really thought a couple of steps ahead and they've said, you know what, if we want our CBDC to be successful, we really should consider making it programmable in an EVM environment, which I think is fantastic. Now, I have urged them to go one step further and just plug their whole CBDC into public Ethereum. I'm not sure they're ready for that yet, but what is exciting about this is that in this environment, Brazil has clear banking secrecy laws, and so if I want to trade with you, if I want to do a transaction with you, the Brazilian government doesn't just say privacy is nice. The Brazilian government says you must respect the privacy of your users. You must build privacy enabled applications. And so they have been testing a number of different privacy solutions. What I think is really exciting about Starlight compared to some of the other ones is that it is...our whole goal in building Starlight Nightfall is to be 100% compatible with an EVM environment where you use native Ethereum tokens like ERC20s and 721s. You preserve all of the true native Ethereum functionality around like the prevention of double spend, the proper management of assets. Our goal is not to create something new. It's to make these things fully compatible and transparent in a very straightforward way. So we want to make it simple. And I think that's a big part of the value proposition. We'll see how Drex evolves, right? But I think this idea of like fully programmable privacy respecting kind of CBDC EVM is quite exciting. Thank you, and I actually lied. You have about three minutes left for this Q&A. Oh, fantastic. So it looks like we've got a couple other questions. What made you choose ZK over Oasis Sapphire or the Secret Network? I assume that's because you guys started back in 2017. It's partly because we started back in 2017, but it's also because, again, we want true, full, native privacy, and one of the things that's also really important to us is that we don't want any kind of off-chain systems that are required. We don't want any special security, like hardware security modules or proprietary tools. Our goal is to have a fully open source ethereum native privacy application with no kind of built-in tax or license or you know system so that was our goal is to be completely open and another question it's more applicable but like I'm curious all the smart contracts that you've developed for NIFOL and Starlight, are they compatible with like just any smart contract and being converted into ZK circuits? Or are there any changes required to satisfy those constraints? So there are some changes. And basically, the Starlight kind of user guide explains how to make those changes, you really do have to be careful. You know, if you design, what you end up with is like a black box. And so if you're not careful, you know, if I have a black box and I have only two parties in it, and I put in $10 and you put in two widgets, it doesn't matter how fancy the logic is in there. From an external point of view, you know that your contract is basically saying the pricing is $5 a widget, right? You've leaked all the meaningful information. So you have to really carefully design your application so that it is optimal for preserving privacy. Before I've got one minute left, I want to talk about this one around privacy for governments and how regulators view this kind of thing. And here's, I want to share with you kind of the one really, really important insight that we have learned in terms of working effectively with regulators. It's really important to help them understand privacy and anonymity are not the same thing. So when we design NYFO, which is our privacy layer two, in order to use it, you need to have an enterprise identity certificate. This doesn't mean that your transactions are visible and there are no back doors in the system, but externally, governments and regulators can see who is transacting. They cannot see what you're doing. They cannot see with whom you are transacting, but they can see that you are transacting. These enterprise ID certificates, X.509s, can only be issued to companies that can pass basic backgrounds and sanctions checks as well. So I would not call it, by the way, KYC, but it is identity. It is a legally accepted form of business identity in many countries, including the United States. And if a regulator comes to you, you can tell them what you're doing and, very importantly, you can also prove to them that what you're sharing with them is truthful. So I think we're done.",
"eventId": "devcon-7",
- "slot_start": 1731469200000,
- "slot_end": 1731469800000,
+ "slot_start": 1731496200000,
+ "slot_end": 1731496800000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Ry_A-NlHMHVJmRMfoIquVsBqvO4xh-ZsvcBax7Ji6fk"
+ "resources_presentation": "https://docs.google.com/presentation/d/12nsOv8WsOMt_04w0HJeyZq7caYnELYCEfrMGbVYyAGM",
+ "resources_slides": null,
+ "speakers": [
+ "max-hampshire",
+ "med-amor"
+ ]
},
"vector": [
0,
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -362036,6 +361286,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -362444,13 +361695,10 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -362540,6 +361788,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -362571,6 +361820,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -362730,13 +361980,10 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -362994,7 +362241,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -363003,60 +362249,50 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "from-packets-to-privacy-understanding-and-evolving-network-security",
- "sourceId": "XYRFXT",
- "title": "From Packets to Privacy: Understanding and Evolving Network Security",
- "description": "This talk will provide a comprehensive journey through the fundamentals of network communication, explore the workings and risks of Virtual Private Networks (VPNs), and dive into the world of Mixnets. We’ll discuss how decentralized Mixnets can offer privacy by default, potentially eliminating the need for traditional VPNs.",
- "track": "Cypherpunk & Privacy",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "id": "from-peerdas-to-fulldas-towards-massive-scalability-with-32mb-blocks-and-beyond",
+ "sourceId": "EVSLDH",
+ "title": "From PeerDAS to FullDAS: towards massive scalability with 32MB blocks and beyond",
+ "description": "PeerDAS is expected to be one of the most interesting improvements of the Pectra hard fork, enabling long-awaited sharding on Ethereum, unleashing L2 scaling.\r\n\r\nPeerDAS is however just the start with up to 1-2 MB of blob space per slot. We look into the techniques jointly developed by our Codex Research Team and EF researchers to improve this by orders of magnitude, targeting 32 MB (and beyond) of data availability space.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Privacy",
- "Anonymity",
- "Censorship Resistance",
- "vpn",
- "Anonymity",
- "Censorship Resistance",
- "Privacy"
- ],
"keywords": [
- "Mixnet",
- "VPN"
+ "PeerDAS",
+ "FullDAS"
+ ],
+ "tags": [
+ "Danksharding",
+ "DAS",
+ "Scalability",
+ "fulldas",
+ "Danksharding",
+ "DAS",
+ "Scalability"
],
- "duration": 529,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "7FyShvrYnHk",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": "6734a0f89dbb7a90e1476ca9",
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67349b569dbb7a90e11ec407.vtt",
- "transcript_text": " On Twitter, you know I promised a joyful and uplifting presentation. I lied. This is going to be pretty pragmatic and realistic. I'm going to tell you about how to use Ethereum and specifically smart contracts to do something useful and interesting with privacy. So, a couple of key topics for today. Number one, let's press the magic button. We're having technical difficulties. So first item I want to talk about is the business case for privacy. And as soon as the clicker works, we will advance to the next slide, which it's not doing. It's not doing that. So anyway, I'm going to talk from a little bit of memory. So pretty much every business agreement comes down to something very simple. I've got money, you've got stuff, and I would like to exchange my money for your stuff under the terms of a business agreement. And the challenge with that is that for companies, they want that information to be private. How much money you have, how much stuff you have, what you're buying, where it's going, that's all like super secret, sensitive business information. Oh, it's working now. So business case for privacy. As I said, companies want to do very simple stuff, exchange money for stuff under the terms of an agreement with privacy. And blockchain is actually this incredible piece of infrastructure for doing this way more efficiently. So we can tokenize the money, we can tokenize the stuff, and we can turn all the business terms and conditions into a programmable set of rules that can be implemented very easily. To make this work, however, we need two kinds of privacy. Number one, we need privacy about the transfer of assets and payments. How much I'm paying you, what you're giving me, where it's going. That stuff needs to be private. But secondly, we also need privacy for the terms and conditions of our agreement. It's really important. If I can read the agreement between company A and company B and it says I'm going to buy 500 widgets at $10 a piece, I'm going to kind of give away all the information that you need to know anyway. So we need these two kinds of privacy. And in particular, pseudo-privacy or mixers or things like that aren't really good enough for businesses because a lot of companies do lots and lots of recurring business with each other, and eventually, if you do enough of these types of transactions, you're going to be traceable even in a public mixer environment, and most business assets are not fungible tokens. Money might be fungible, but the things that you're buying are often not fungible, and anything that's non-fungible becomes instantly traceable in a public environment. So it's really hard to design without leaking information, and that's some of the stuff that we've really been working on. Now, before I talk to you about how, I just want to take a second and talk about what is the value proposition? Why is this worth doing? And I want to share with you a very specific example, which is around the use of smart contracts for business automation. About five years ago, EY and Microsoft worked together to replace the procurement system for the Xbox video game network with a set of smart contracts. And the idea here was to replace an existing system which had a traditional ERP system, and it was sort of semi-automated. At the end of each month, they would look at all the transactions, and they would manually apply some of the rules that they had implemented between Microsoft and their 3,000-odd gaming suppliers. Well, it took, on average, in the old system, about 45 days to calculate how much they were owed and go through all the individual contracts and special rules. When we turn those into blockchain-based smart contracts, the beauty of these kind of smart contracts is they're basically scripts, right? It doesn't matter. As long as the rules that you and I have agreed upon are logical and clear, then I can automate them and they can run properly. And the result was that we basically took a process that used to take 45 days and we brought it down to about five minutes, right? That is a good improvement. And we did it for about half the cost of the existing system. So the value proposition of being able to take a complex business agreement and turn it into an automated smart contract is incredibly large. The problem that we had at the time was we didn't know how to do this under privacy on a public blockchain. Eventually, where we want to go to is this ability to put together tokenization with smart contracts and in a way that you can create a complete business model that's running on chain. In this picture, what we have is a very typical supply chain, right? Raw materials, they get manufactured, they get transported, they get put in a warehouse, they get sold to a customer, and then they get supported. Now, every single item in a traditional manufacturing supply chain we can represent as a token. Some of the things are fungible tokens, most of them are non-fungible tokens. Anything with a serial number becomes a non-fungible token. And so basically in this picture, stuff moves from left to right, and money moves from right to left, and a set of smart contracts governs this movement of the process away. And not only can we run the business process for about half the cost, but we can also run the supply chain much more efficiently. We think we can typically, if we move from traditional supply chain models to a tokenized supply chain model with all the rules of preventing double spend, you can actually cut maybe as much as 20% of the inventory from your supply chain and have the same service level. So in short, this is worth crazy amounts of money. Now, let's talk about a specific use case that we are implementing for clients and rolling out worldwide, and this is renewable energy. And I want to talk about why renewable energy is such an incredible use case and application and how we got there. I want to start with the roadmap for privacy that we are working on at EY. We've got two applications that we're building. I talked about two types of privacy that we are working on at EY. We've got two applications that we're building. I talked about two types of privacy that we want to do. One is privacy of moving stuff around, and the other is privacy of the terms and conditions of a business agreement. So for the privacy of tokenization and moving things around, we have created a Layer 2 ZK rollup called Nightfall. Nightfall allows you to move around fungible and non-fungible tokens. It's an EVM compatible layer two, so it actually can run on top of the main net. It can also run on top of, say, a layer two as a layer three. So Nightfall is for moving stuff around. Starlight is a transpiler that basically takes a Solidity Smart contract and turns it into a set of zero knowledge circuit. Our idea, our concept is to get each one of these pieces working independently and then bring them together so that you can have this full business to business kind of complex road map. Both of these, to be clear, are, although they are largely developed by EY, we have put them into the public domain. They are public domain, open source contributions to the Ethereum ecosystem. There are no proprietary gotchas here. There are no surprise, like, you know, special terms and conditions in the open source license. It is full public domain. We have relinquished all ownership to these assets. Thank you, sir. That is how much we love and believe in the Ethereum ecosystem. And we have been on this journey for a while, by the way. I know we're getting a lot of attention from the Noir program that's launched this week. I tell you that we started about the same time as the folks at Aztec, and most of our team is across town from them in London. And one of the things that delights me so much is to come to DevCon and see how much competition is now in the privacy space. I really believe that even if we lose in a competitive race with some of the other solutions, we win. But I'm not yet given up on losing. We have been on this journey for a while, even though the numbers didn't sort of look out correctly. We started in 2017. And here we are in 2024. We're on Nightfall version 4. Nightfall version 3, which is currently in production, is a ZK optimistic roll-up. ZK for privacy, optimism for finality. Nightfall version 4, which we showed off earlier this year and will be in production next year, is a ZK, ZK roll-up. So one ZK for privacy and one for instant finality. All right, let's talk about renewable energy and exactly how we implemented this. So the way that renewable energy contracts work, and the reason why they're such a good candidate for zero knowledge applications is that they are kind of complicated. And this is a simplified version. Very simply, you got a power buy. You got somebody, they got a factory, they want electricity, they want a lot of electricity, they're going to buy it from somebody. But maybe they're a large company, they have a good social responsibility plan, they have committed to become carbon neutral. So what power buyers do is they reach an agreement with a renewable energy seller, somebody who's got solar facilities, battery facilities, whatever it is that's renewable and fully green. Here's the problem. Electrons are fungible, right? You might want to have your locally produced organic artisanal electrons, but actually the way it works is you have to take what the power company is giving you. And so what happens is the power buyer basically buys electricity from the power company at whatever the market price is in their environment. The power company in turn buys power from a whole bunch of suppliers. Some of them are very green, some of them are not so green. The agreement exists between the renewable seller and the renewable buyer. And what the smart contract does is it basically keeps track of the market price that the power buyer paid to the electric company and the difference between that and the agreed upon price and then they settle up usually every month or so if one party owes the other. And there's usually complex terms and conditions like a commitment to buy a certain minimum amount of power in the grid or a certain maximum price that they have to pay. And the idea is that they are basically providing the incentive and enough financial value to the renewable provider to structure long-term investment. And these renewable energy contracts are incredibly important because a lot of these solar facilities, wind facilities, they could not be built without the advanced commitment of buyers like these kinds of factories or other companies that are committed to be carbon neutral. These advanced commitments that they make, they're often five or ten years at a certain price for a certain number of megawatts. These are incredibly important to guaranteeing the revenue that provides the investment funding to build these kinds of facilities. Right, so that's what the structure is. So a little bit like, you know, video game contracts with thresholds and minimums and rebates, renewable energy contracts can be quite complex. To build this renewable energy contract, we went through a multi-step process, which I want to explain. We started by just creating a Solidity smart contract without privacy that followed the terms and conditions that we wanted to implement. And once we had that working, we created a modified Solidity application, which we call a Solidity application. And all we did was mark up the variables and the logic that we want to be private. So we have a little guide on how to do this. And then we put that into the Starlight transpiler. And what that does is it spits out a zero-knowledge circuit, a whole application that you can run on-chain, which we call a ZAP, right, for a zero knowledge app. And please don't ask me who is in charge of our naming, but there's a lot of Zs in there. And so the idea here is to keep it very simple. And Starlight itself came out of a really important learning experience we had. So about three or four years ago, we tried to teach our research team, our PhD mathematicians, tried to sit down and teach our developers how to write zero knowledge circuits using tools like Socrates. It was a spectacular train wreck. Like, it just did not work at all. Our solidity developers were like, this is too difficult. I don't like this. I don't want to do this. And so we went back to the drawing board and we said, we need to find a way to make this much easier and much simpler, and you just should have to do some minor changes to a Solidity smart contract. And that's how we ended up with Starlight. So Starlight is really designed to be as easy as possible. It allows you to take a Solidity application that you know already works and turn it into a zero-knowledge application. You still have to think very carefully about how to design it in such a way that you're not going to leak really sensitive metadata. Because if you're not careful, you will accidentally end up leaking metadata. But the goal is to get to the point where anybody can do applications. As I said, it's public domain and open source. You can go and try it out yourself. There are currently about 100 companies worldwide that are designing and testing applications using Starlight. And in particular, we've been working very closely with the Central Bank of Brazil. We have about 60 or 70 banks in Brazil that are testing out Starlight-based applications. And for the last year, we've been working really hard to refine the Starlight application development process and tooling. Right now, where we are is that we are in a kind of a stateless environment. So the Starlight application receives data, it calculates the amounts owed, but it does not store anything on-chain, it doesn't store any commitments even off-chain, it's a stateless component, and transactions are relatively inexpensive, provided you deploy them on a layer two network. The future path is that we want to integrate Starlight with on-chain payment and with some level of off-chain stateful storage of things like the amount of electricity consumed and the amount of money paid so that you really have a proper continuous record of the entire set of business transactions. But that's the goal. As I said, we're following a kind of crawl, walk, run strategy, and the goal is to start and build things that are very pragmatic and useful to business users rather than try to bite off the whole thing at once. So we have fundamentally a bit of a different approach than, say, Aztec or some of the others who I think have a very ambitious and kind of complete approach. We welcome participation. Our content, it's public domain, it's open source. All of our tools are open and available, and we publish them on the EY blockchain site on GitHub. So that's really important to us. We have many, many contributors, but underpinning all of this is kind of a long-term commitment from EY to invest in privacy because we believe it is the one thing that enterprises need in order to get fully engaged with on-chain business and to give up this fixation that a lot of people have with private blockchains. Lastly, we are here. We have an impact booth. Our research team is here, and quite a few members of our engineering team as well. We would love to talk to you about how to help you make privacy-enabled applications that are regulatory compliant. They will not end you up in jail. I feel like I myself would not do very well in prison, so I don't want to go there. And then lastly, I'm ready to take a couple questions, but I also want to share with you my little QR code. It will take you to a website that will give you what we call a proof of Paul NFT, which is minted on the Polygon proof of stake blockchain, and we made a special one just for DevCon. So, am I on time? Have we got enough time for a couple minutes of questions? Yeah, we've got some time. We've got about six, seven minutes. Perfect. So, we've actually got a lot of questions, but feel free to ask some more on here. So, it looks like the top question here is, why did you build Nightfall rather than contribute to other open source ZK roll-ups? Well, at the time that we got started, there weren't any other open source ZK roll-ups. I mean, this was seven years ago. And by the way, almost all the ZK roll-ups that are out there are ZK for scaling, not ZK for privacy. And in fact, one of my frustrations was, you know, seven, eight years ago when we got started down this path, everyone's like, hey, we got to fix the scaling problem for Ethereum. And while I agree with that, and I'm really pleased with the progress that Ethereum has made on scaling, I think it's incredible. And the end of the day for business users, there's no scaling. The scaling problem is not a problem until you solve the privacy problem. Without privacy, no business user is going to touch Ethereum. And I want every business agreement in the future to be on Ethereum. Awesome. Well, how do you tokenize real-world assets without them being centralized? That's a great question. So I think, let's see here. I guess the quick answer is, I think for individual companies, those assets are going to be, if you're tokenizing your own assets, it is going to be, to a certain degree, centralized in your company. And this is kind of an issue that we've talked about a lot with other people, is in certain circumstances, there are some things where only one participant really knows the status of that asset. The only company that knows where your UPS or FedEx package is, is UPS or FedEx, right? And so you have to accept that. And one thing that is a really cool thing is there's a process, a well-accepted business process from the world of TradFi. It's called a SOC audit, right, which is a systems and organizations control. And what it is, is you have an independent organization come in and assess your reporting mechanism. And so in the cases where you can't have proper decentralization, you should have external auditing and testing to make it more reliable. And I think we have time for one more question. Can you talk about the Brazilian CBDC and how the experience is of using Starlight on Drex? And for my sake, can you explain what Drex is? Yes. So Brazil has a really cool, they've had some really cool thoughts about their CBDC. So as many of you may know, CBDCs are really struggling with acceptance and success because they don't offer a lot of value. The Brazilian Central Bank has taken note of that and they've really thought a couple of steps ahead and they've said, you know what, if we want our CBDC to be successful, we really should consider making it programmable in an EVM environment, which I think is fantastic. Now, I have urged them to go one step further and just plug their whole CBDC into public Ethereum. I'm not sure they're ready for that yet, but what is exciting about this is that in this environment, Brazil has clear banking secrecy laws, and so if I want to trade with you, if I want to do a transaction with you, the Brazilian government doesn't just say privacy is nice. The Brazilian government says you must respect the privacy of your users. You must build privacy enabled applications. And so they have been testing a number of different privacy solutions. What I think is really exciting about Starlight compared to some of the other ones is that it is...our whole goal in building Starlight Nightfall is to be 100% compatible with an EVM environment where you use native Ethereum tokens like ERC20s and 721s. You preserve all of the true native Ethereum functionality around like the prevention of double spend, the proper management of assets. Our goal is not to create something new. It's to make these things fully compatible and transparent in a very straightforward way. So we want to make it simple. And I think that's a big part of the value proposition. We'll see how Drex evolves, right? But I think this idea of like fully programmable privacy respecting kind of CBDC EVM is quite exciting. Thank you, and I actually lied. You have about three minutes left for this Q&A. Oh, fantastic. So it looks like we've got a couple other questions. What made you choose ZK over Oasis Sapphire or the Secret Network? I assume that's because you guys started back in 2017. It's partly because we started back in 2017, but it's also because, again, we want true, full, native privacy, and one of the things that's also really important to us is that we don't want any kind of off-chain systems that are required. We don't want any special security, like hardware security modules or proprietary tools. Our goal is to have a fully open source ethereum native privacy application with no kind of built-in tax or license or you know system so that was our goal is to be completely open and another question it's more applicable but like I'm curious all the smart contracts that you've developed for NIFOL and Starlight, are they compatible with like just any smart contract and being converted into ZK circuits? Or are there any changes required to satisfy those constraints? So there are some changes. And basically, the Starlight kind of user guide explains how to make those changes, you really do have to be careful. You know, if you design, what you end up with is like a black box. And so if you're not careful, you know, if I have a black box and I have only two parties in it, and I put in $10 and you put in two widgets, it doesn't matter how fancy the logic is in there. From an external point of view, you know that your contract is basically saying the pricing is $5 a widget, right? You've leaked all the meaningful information. So you have to really carefully design your application so that it is optimal for preserving privacy. Before I've got one minute left, I want to talk about this one around privacy for governments and how regulators view this kind of thing. And here's, I want to share with you kind of the one really, really important insight that we have learned in terms of working effectively with regulators. It's really important to help them understand privacy and anonymity are not the same thing. So when we design NYFO, which is our privacy layer two, in order to use it, you need to have an enterprise identity certificate. This doesn't mean that your transactions are visible and there are no back doors in the system, but externally, governments and regulators can see who is transacting. They cannot see what you're doing. They cannot see with whom you are transacting, but they can see that you are transacting. These enterprise ID certificates, X.509s, can only be issued to companies that can pass basic backgrounds and sanctions checks as well. So I would not call it, by the way, KYC, but it is identity. It is a legally accepted form of business identity in many countries, including the United States. And if a regulator comes to you, you can tell them what you're doing and, very importantly, you can also prove to them that what you're sharing with them is truthful. So I think we're done.",
- "eventId": "devcon-7",
- "slot_start": 1731496200000,
- "slot_end": 1731496800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/12nsOv8WsOMt_04w0HJeyZq7caYnELYCEfrMGbVYyAGM",
- "resources_slides": null,
"speakers": [
- "max-hampshire",
- "med-amor"
- ]
+ "csaba-kiraly"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731575400000,
+ "slot_end": 1731577200000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1lz7gYMVKQCLb5914Y9OWEh4uWk8dcQ8g132fAtGQIuQ"
},
"vector": [
0,
0,
0,
0,
- 0,
6,
0,
0,
@@ -363415,10 +362651,9 @@
0,
0,
0,
- 6,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -363830,7 +363065,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -363869,6 +363103,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -363920,7 +363155,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -363944,6 +363178,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -363952,7 +363187,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -364159,6 +363393,7 @@
0,
0,
2,
+ 2,
0,
0,
0,
@@ -364369,12 +363604,11 @@
0,
2,
0,
+ 2,
0,
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -364387,45 +363621,42 @@
},
{
"session": {
- "id": "from-peerdas-to-fulldas-towards-massive-scalability-with-32mb-blocks-and-beyond",
- "sourceId": "EVSLDH",
- "title": "From PeerDAS to FullDAS: towards massive scalability with 32MB blocks and beyond",
- "description": "PeerDAS is expected to be one of the most interesting improvements of the Pectra hard fork, enabling long-awaited sharding on Ethereum, unleashing L2 scaling.\r\n\r\nPeerDAS is however just the start with up to 1-2 MB of blob space per slot. We look into the techniques jointly developed by our Codex Research Team and EF researchers to improve this by orders of magnitude, targeting 32 MB (and beyond) of data availability space.",
- "track": "Core Protocol",
+ "id": "from-web2-security-with-love",
+ "sourceId": "VYEKSS",
+ "title": "From Web2 Security With Love",
+ "description": "Web3 organizations often rely on Web2 for infrastructure, communications, and development, yet their Web2 security posture is often neglected. This leaves them vulnerable to a wide range of adversaries, from well-funded sophisticated attackers to opportunistic script kiddies. In this talk,Joe Dobson will share hard-earned lessons from the Web2 trenches that can help secure Web3.Don’t make it easy for the adversary. Learn from the past: strengthen your Web2 security to safeguard your Web3 future.",
+ "track": "Security",
"type": "Talk",
- "expertise": "Expert",
- "audience": "Research",
+ "expertise": "Beginner",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "PeerDAS",
- "FullDAS"
+ "Intelligence"
],
"tags": [
- "Danksharding",
- "DAS",
- "Scalability",
- "fulldas",
- "Danksharding",
- "DAS",
- "Scalability"
+ "Security",
+ "Hacks",
+ "intelligence",
+ "Hacks",
+ "Security"
],
"language": "en",
"speakers": [
- "csaba-kiraly"
+ "joe-dobson"
],
"eventId": "devcon-7",
- "slot_start": 1731575400000,
- "slot_end": 1731577200000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1lz7gYMVKQCLb5914Y9OWEh4uWk8dcQ8g132fAtGQIuQ"
+ "slot_start": 1731574800000,
+ "slot_end": 1731576600000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Q9J9HaQFEJ3SPx50bpp3xIlPzaHzn4kJ8ESPA0lnVoI"
},
"vector": [
+ 6,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -365170,6 +364401,13 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -365238,7 +364476,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -365313,7 +364550,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -365415,6 +364651,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -365528,23 +364772,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -365751,49 +364978,48 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "from-web2-security-with-love",
- "sourceId": "VYEKSS",
- "title": "From Web2 Security With Love",
- "description": "Web3 organizations often rely on Web2 for infrastructure, communications, and development, yet their Web2 security posture is often neglected. This leaves them vulnerable to a wide range of adversaries, from well-funded sophisticated attackers to opportunistic script kiddies. In this talk,Joe Dobson will share hard-earned lessons from the Web2 trenches that can help secure Web3.Don’t make it easy for the adversary. Learn from the past: strengthen your Web2 security to safeguard your Web3 future.",
- "track": "Security",
- "type": "Talk",
- "expertise": "Beginner",
+ "id": "future-of-onchain-credit-scoring-for-farmers",
+ "sourceId": "BBEDYL",
+ "title": "Future of Onchain Credit Scoring for Farmers",
+ "description": "This talk will illustrate how a farmer's farm records alongside verified government issued ID and mobile money statements (M-Pesa) form the basis for anonymized real time credit scoring onchain, as a foundational layer to build unique farmer DIDs. This talk features Antugrow, a startup in Kenya re-imagining credit scoring and record keeping for farmers.",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
- "doNotRecord": false,
+ "doNotRecord": true,
"keywords": [
- "Intelligence"
+ "Agriculture"
],
"tags": [
- "Security",
- "Hacks",
- "intelligence",
- "Hacks",
- "Security"
+ "Identity",
+ "agriculture",
+ "Identity"
],
"language": "en",
"speakers": [
- "joe-dobson"
+ "eddie-kago"
],
"eventId": "devcon-7",
- "slot_start": 1731574800000,
- "slot_end": 1731576600000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1Q9J9HaQFEJ3SPx50bpp3xIlPzaHzn4kJ8ESPA0lnVoI"
+ "slot_start": 1731580200000,
+ "slot_end": 1731580800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/143aux2LnIoaZxJqy3DpwpFTohgfllg9LWtuYzwx2v78"
},
"vector": [
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -366539,9 +365765,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -366588,6 +365811,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -366790,10 +366014,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -366896,6 +366118,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -367100,9 +366323,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
2,
0,
@@ -367122,41 +366345,42 @@
},
{
"session": {
- "id": "future-of-onchain-credit-scoring-for-farmers",
- "sourceId": "BBEDYL",
- "title": "Future of Onchain Credit Scoring for Farmers",
- "description": "This talk will illustrate how a farmer's farm records alongside verified government issued ID and mobile money statements (M-Pesa) form the basis for anonymized real time credit scoring onchain, as a foundational layer to build unique farmer DIDs. This talk features Antugrow, a startup in Kenya re-imagining credit scoring and record keeping for farmers.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
+ "id": "fuzzing-zero-knowledge-infrastructure",
+ "sourceId": "QYWS83",
+ "title": "Fuzzing Zero-Knowledge Infrastructure",
+ "description": "Zero-knowledge (ZK) infrastructure is highly complex and highly critical for the correct operation of L2 chains; that is, a single bug can result in massive financial and reputational damage. To find such potential million-dollar bugs before they are exploited, we have developed a novel fuzzing technique that can find logic flaws that impact liveness or safety of ZK infrastructure. Our fuzzer has already found 16 such issues in four ZK systems, namely Circom, Corset, Gnark, and Noir.",
+ "track": "Security",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
- "doNotRecord": true,
+ "doNotRecord": false,
"keywords": [
- "Agriculture"
+ "Metamorphic",
+ "Testing"
],
"tags": [
- "Identity",
- "agriculture",
- "Identity"
+ "ZKP",
+ "Zero-Knowledge",
+ "Security",
+ "Fuzzing",
+ "Testing",
+ "metamorphic",
+ "Fuzzing",
+ "Security",
+ "Zero-Knowledge"
],
"language": "en",
"speakers": [
- "eddie-kago"
+ "valentin-wustholz"
],
"eventId": "devcon-7",
- "slot_start": 1731580200000,
- "slot_end": 1731580800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/143aux2LnIoaZxJqy3DpwpFTohgfllg9LWtuYzwx2v78"
+ "slot_start": 1731641400000,
+ "slot_end": 1731643200000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1C0qMB9Xtv-bWWVg8T0URvn0L0LP0y88aiS1n8-LmL1U"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -367518,14 +366742,13 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -367907,6 +367130,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -367917,6 +367142,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -367952,7 +367178,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -367980,6 +367205,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -368144,6 +367370,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -368468,8 +367695,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -368486,47 +367713,47 @@
},
{
"session": {
- "id": "fuzzing-zero-knowledge-infrastructure",
- "sourceId": "QYWS83",
- "title": "Fuzzing Zero-Knowledge Infrastructure",
- "description": "Zero-knowledge (ZK) infrastructure is highly complex and highly critical for the correct operation of L2 chains; that is, a single bug can result in massive financial and reputational damage. To find such potential million-dollar bugs before they are exploited, we have developed a novel fuzzing technique that can find logic flaws that impact liveness or safety of ZK infrastructure. Our fuzzer has already found 16 such issues in four ZK systems, namely Circom, Corset, Gnark, and Noir.",
- "track": "Security",
+ "id": "gas-limit-and-block-execution",
+ "sourceId": "LPLSDD",
+ "title": "Gas Limit and Block Execution",
+ "description": "The talk will focus on scaling L1 through the gas limit, with special attention to block execution, covering challenges and planned solutions. Topics include an overview of control over the gas limit, the current state of execution performance, and hardware comparisons. Key challenges will also be discussed, such as slot organization, state growth, and worst-case scenarios, including gas pricing issues.",
+ "track": "Core Protocol",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Stakers/Validators",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Metamorphic",
- "Testing"
+ "gas limit",
+ "block execution",
+ "Execution Layer"
],
"tags": [
- "ZKP",
- "Zero-Knowledge",
- "Security",
- "Fuzzing",
- "Testing",
- "metamorphic",
- "Fuzzing",
- "Security",
- "Zero-Knowledge"
+ "Core Protocol",
+ "Layer 1",
+ "Protocol Design",
+ "execution",
+ "layer",
+ "Core Protocol",
+ "Layer 1",
+ "Protocol Design"
],
"language": "en",
"speakers": [
- "valentin-wustholz"
+ "marekm25"
],
"eventId": "devcon-7",
- "slot_start": 1731641400000,
- "slot_end": 1731643200000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1C0qMB9Xtv-bWWVg8T0URvn0L0LP0y88aiS1n8-LmL1U"
+ "slot_start": 1731566400000,
+ "slot_end": 1731568200000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/17JZL3bUgGRPxJs5ybdBTY70V_NqPo7xH7Sc7QI5zw5A"
},
"vector": [
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -369274,10 +368501,6 @@
0,
0,
0,
- 6,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -369286,14 +368509,15 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -369320,6 +368544,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -369349,7 +368574,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -369469,6 +368693,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -369515,7 +368740,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -369840,12 +369064,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -369857,50 +369081,47 @@
},
{
"session": {
- "id": "gas-limit-and-block-execution",
- "sourceId": "LPLSDD",
- "title": "Gas Limit and Block Execution",
- "description": "The talk will focus on scaling L1 through the gas limit, with special attention to block execution, covering challenges and planned solutions. Topics include an overview of control over the gas limit, the current state of execution performance, and hardware comparisons. Key challenges will also be discussed, such as slot organization, state growth, and worst-case scenarios, including gas pricing issues.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Stakers/Validators",
+ "id": "gas-metering-comparing-appchain-rollups-vs-general-purpose-rollups",
+ "sourceId": "KXFHXJ",
+ "title": "Gas Metering: Comparing Appchain Rollups vs. General Purpose Rollups",
+ "description": "General purpose rollups, with all applications running in the same virtual machine, face specific constraints in their gas metering systems that appchain rollups do not.\r\n\r\nIn this lightning talk, we'll explore the differences and the design freedom in gas metering when your application isn't in an adversarial setting, avoiding potential attacks from newly deployed code. Discover the benefits and challenges of customized gas metering in appchain rollups.",
+ "track": "Layer 2",
+ "type": "Lightning Talk",
+ "expertise": "Expert",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "gas limit",
- "block execution",
- "Execution Layer"
+ "Metering"
],
"tags": [
- "Core Protocol",
- "Layer 1",
- "Protocol Design",
- "execution",
- "layer",
- "Core Protocol",
- "Layer 1",
- "Protocol Design"
+ "Gas",
+ "Appchains",
+ "Mechanism design",
+ "metering",
+ "Appchains",
+ "Gas",
+ "Mechanism design"
],
"language": "en",
"speakers": [
- "marekm25"
+ "felipe-argento"
],
"eventId": "devcon-7",
- "slot_start": 1731566400000,
- "slot_end": 1731568200000,
+ "slot_start": 1731583200000,
+ "slot_end": 1731583800000,
"slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/17JZL3bUgGRPxJs5ybdBTY70V_NqPo7xH7Sc7QI5zw5A"
+ "resources_presentation": "https://docs.google.com/presentation/d/1RCYOul1XxqYV0BU6bMqResTDK6sazsIhKVB2ctdgBKU"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -370649,6 +369870,16 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -370660,11 +369891,9 @@
0,
0,
0,
- 6,
0,
0,
0,
- 2,
0,
0,
0,
@@ -370691,7 +369920,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -370840,7 +370068,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -370863,6 +370090,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -370956,6 +370191,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -370983,6 +370222,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -371004,28 +370247,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -371208,6 +370429,7 @@
0,
2,
0,
+ 2,
0,
0,
0,
@@ -371216,10 +370438,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -371228,37 +370446,40 @@
},
{
"session": {
- "id": "gas-metering-comparing-appchain-rollups-vs-general-purpose-rollups",
- "sourceId": "KXFHXJ",
- "title": "Gas Metering: Comparing Appchain Rollups vs. General Purpose Rollups",
- "description": "General purpose rollups, with all applications running in the same virtual machine, face specific constraints in their gas metering systems that appchain rollups do not.\r\n\r\nIn this lightning talk, we'll explore the differences and the design freedom in gas metering when your application isn't in an adversarial setting, avoiding potential attacks from newly deployed code. Discover the benefits and challenges of customized gas metering in appchain rollups.",
- "track": "Layer 2",
+ "id": "giga-staking-for-school-connectivity",
+ "sourceId": "ZU3AEJ",
+ "title": "Giga: Staking for school connectivity",
+ "description": "Giga is a joint venture between UNICEF and the ITU with the mission of connecting all the world's schools to the internet. Over the past years, a novel approach to fund the ongoing operating expenses of school connectivity has been running as a pilot in Rwanda and Giga is currently scaling up operations.\r\n\r\nAs part of this pilot, one staking node has been generating returns that are being spent on connectivity in a school in Rwanda. All of this has been done in compliance with local regulations.",
+ "track": "Real World Ethereum",
"type": "Lightning Talk",
- "expertise": "Expert",
- "audience": "Research",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Metering"
+ "connectivity",
+ "schools",
+ "social impact"
],
"tags": [
- "Gas",
- "Appchains",
- "Mechanism design",
- "metering",
- "Appchains",
- "Gas",
- "Mechanism design"
+ "Staking",
+ "Sustainability",
+ "Ethereum for Good",
+ "Social",
+ "impact",
+ "Ethereum for Good",
+ "Staking",
+ "Sustainability"
],
"language": "en",
"speakers": [
- "felipe-argento"
+ "gerben-kijne"
],
"eventId": "devcon-7",
- "slot_start": 1731583200000,
- "slot_end": 1731583800000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1RCYOul1XxqYV0BU6bMqResTDK6sazsIhKVB2ctdgBKU"
+ "slot_start": 1731577200000,
+ "slot_end": 1731577800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1rmmBw3SZZEyNNDi7PgdUEMlN6Wfogmt3EIpC8WZe-5I"
},
"vector": [
0,
@@ -371267,7 +370488,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -371631,6 +370851,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -372020,7 +371241,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -372137,8 +371357,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -372189,6 +371411,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -372241,7 +371464,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -372274,6 +371496,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -372342,7 +371565,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -372358,6 +371580,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -372373,7 +371596,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -372572,12 +371794,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
2,
0,
@@ -372587,49 +371809,40 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "giga-staking-for-school-connectivity",
- "sourceId": "ZU3AEJ",
- "title": "Giga: Staking for school connectivity",
- "description": "Giga is a joint venture between UNICEF and the ITU with the mission of connecting all the world's schools to the internet. Over the past years, a novel approach to fund the ongoing operating expenses of school connectivity has been running as a pilot in Rwanda and Giga is currently scaling up operations.\r\n\r\nAs part of this pilot, one staking node has been generating returns that are being spent on connectivity in a school in Rwanda. All of this has been done in compliance with local regulations.",
+ "id": "giga-undepin-to-connect-every-school-in-the-world",
+ "sourceId": "JXH3T3",
+ "title": "Giga: (UN)DePIN to connect every school in the world",
+ "description": "Giga (a startup built by UNICEF and ITU) has built a long-lasting friendship with the Ethereum community, starting w/ the 2019 Devcon launch of UNICEF's Crypto Fund, to the first Eth staking with the Government of Rwanda, putting schools onchain, and now working on a global Connectivity Credits Marketplace.\r\n \r\nBlockchain, and particularly Ethereum, is fundamental to scaling connectivity for the 1.8 billion people who aren't online. http://giga.global",
"track": "Real World Ethereum",
- "type": "Lightning Talk",
+ "type": "Talk",
"expertise": "Beginner",
"audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "connectivity",
- "schools",
- "social impact"
+ "Connectivity",
+ "real world digital assets",
+ ""
],
"tags": [
- "Staking",
- "Sustainability",
- "Ethereum for Good",
- "Social",
- "impact",
+ "DePIN",
"Ethereum for Good",
- "Staking",
- "Sustainability"
+ "Politics"
],
"language": "en",
"speakers": [
- "gerben-kijne"
+ "christopher-fabian"
],
"eventId": "devcon-7",
- "slot_start": 1731577200000,
- "slot_end": 1731577800000,
+ "slot_start": 1731576000000,
+ "slot_end": 1731577200000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1rmmBw3SZZEyNNDi7PgdUEMlN6Wfogmt3EIpC8WZe-5I"
+ "resources_presentation": "https://docs.google.com/presentation/d/1Kux95LlPqrqyaIMbQZgE8OhOIzJM8A61evcBSSNF7dY"
},
"vector": [
0,
@@ -373403,6 +372616,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -373506,14 +372720,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
- 0,
0,
- 2,
0,
0,
0,
@@ -373564,7 +372776,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -373650,7 +372861,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -373718,6 +372928,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -373734,7 +372945,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -373967,44 +373177,36 @@
},
{
"session": {
- "id": "giga-undepin-to-connect-every-school-in-the-world",
- "sourceId": "JXH3T3",
- "title": "Giga: (UN)DePIN to connect every school in the world",
- "description": "Giga (a startup built by UNICEF and ITU) has built a long-lasting friendship with the Ethereum community, starting w/ the 2019 Devcon launch of UNICEF's Crypto Fund, to the first Eth staking with the Government of Rwanda, putting schools onchain, and now working on a global Connectivity Credits Marketplace.\r\n \r\nBlockchain, and particularly Ethereum, is fundamental to scaling connectivity for the 1.8 billion people who aren't online. http://giga.global",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "going-from-alzheimers-to-pandemics-bringing-floss-to-bio-testing",
+ "sourceId": "PZACPB",
+ "title": "Going from Alzheimer's to Pandemics: Bringing FLOSS to Bio Testing",
+ "description": "Varro has developed a unique semiconductor-based biosensor platform that detects pathogens in human breath and indoor air with significant improvements in speed, sensitivity, and cost over existing technologies. The platform will be offered via open source to expand its reach and accessibility. We will discuss the core technology and how it can be used to prevent the spread of disease and new pandemics around the world.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Connectivity",
- "real world digital assets",
- ""
- ],
- "tags": [
- "DePIN",
- "Ethereum for Good",
- "Politics"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
"speakers": [
- "christopher-fabian"
+ "tom-cirrito-phd"
],
"eventId": "devcon-7",
- "slot_start": 1731576000000,
- "slot_end": 1731577200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Kux95LlPqrqyaIMbQZgE8OhOIzJM8A61evcBSSNF7dY"
+ "slot_start": 1731569700000,
+ "slot_end": 1731570600000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1JN8fHkrJUSmMwQcFE6vbbWGfFN8h8mUo1A7pu-plAU8"
},
"vector": [
0,
+ 6,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -374772,8 +373974,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -374876,7 +374076,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -375085,7 +374284,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -375316,11 +374514,12 @@
2,
0,
0,
+ 2,
+ 0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -375333,31 +374532,58 @@
},
{
"session": {
- "id": "going-from-alzheimers-to-pandemics-bringing-floss-to-bio-testing",
- "sourceId": "PZACPB",
- "title": "Going from Alzheimer's to Pandemics: Bringing FLOSS to Bio Testing",
- "description": "Varro has developed a unique semiconductor-based biosensor platform that detects pathogens in human breath and indoor air with significant improvements in speed, sensitivity, and cost over existing technologies. The platform will be offered via open source to expand its reach and accessibility. We will discuss the core technology and how it can be used to prevent the spread of disease and new pandemics around the world.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "id": "governance-innovation-analysis-on-voter-behavior-in-blockchain-governance",
+ "sourceId": "ZKNSAL",
+ "title": "Governance Innovation: Analysis on Voter Behavior in Blockchain Governance",
+ "description": "As the first comprehensive examination of voter behavior in Web3, the following research explores two significant blockchain ecosystems, Curve Finance and Polkadot, using a novel quantitative methodology to decompose and highlight governance patterns.\r\n\r\nThe presented analysis shows, among other findings, a significant influence of market conditions on voter tendencies, diverse patterns relating to voting power accumulation, and a potential effect of financial incentives on voter participation.",
+ "track": "Coordination",
"type": "Lightning Talk",
- "expertise": "",
- "audience": "Engineering",
+ "expertise": "Expert",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
- "language": "en",
- "speakers": [
- "tom-cirrito-phd"
+ "tags": [
+ "Permissionless",
+ "Coordination",
+ "Governance",
+ "Decentralization",
+ "Game Theory",
+ "Tokenomics",
+ "voting",
+ "analytics",
+ "Coordination",
+ "Decentralization",
+ "Game Theory",
+ "Governance",
+ "Permissionless",
+ "Tokenomics"
+ ],
+ "keywords": [
+ "Vote Escrow",
+ "Funding Allocation",
+ "Voter Analytics"
],
+ "duration": 535,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "wLw9Xvigdqs",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673476c59dbb7a90e1392576.vtt",
+ "transcript_text": " Hello, everyone. Thank you so much for taking the time to join in. In this specific talk, we're going to cover about governance, and it will assume that you have a basic understanding of governance already. Another thing that this talk is going to do is drop a lot of QR codes because there's quite a few innovations I want to cover so you can go apply it in your worlds and the QR codes will help you dive deep into specific topics that you want to dive deep into. Let's start with innovation number one and this is so often like overlooked. Let's face it, right? Be it grants, be it governance, be it decision-making, the voter's perception is at the end of the day, your reality. And the user experience and governance is an area of innovation that's not very much focused on. This is where we have an interesting product we just launched, which kind of shows you how you can delegate in one of the simplest user experiences possible. You can select the percentage that you want to delegate. You exactly know what's your voting power going to look like, and then you delegate. And that's simple. And this is one area where we're trying to make user experience as less fragmented as possible. And if you'd like to read more about the thinking, the transparency, the ethos, the on-chain activities that went into designing a governance hub, I highly recommend scanning the QR code and jumping into it. Now, let's talk about not just the user experience. Let's go a little bit deeper, right? We did a research on how exactly voter behavior works out. We took two vote escrow systems. One, we took Polkadot. The other, we took Curve. Both of them require you to lock in your tokens and in return, you get a certain voting power. That voting power is decayed over a period of time. But there's one fundamental difference. Curve has a financial incentive mechanism to it. Every Thursday, you use your VE Curve tokens and you get APYs based on how the treasury allocates funds. Polkadot not necessarily has financial incentives attached to it. Now, you will see some very interesting insights. So in Curve, 65% of Curve is logged as Vcurve. And out of the 65% that's logged, an average of 38% is used for voting. What do you think that number would look like for Polkadot, one that doesn't have financial incentives? Well, 54% is locked in multiple Polkadot lockers. And it's, you know, a shockingly low 0.11% that's used for voting. And you can see how financial incentives play out a huge role in possibly this disparity. Let's go a bit deeper into another data point. In Curve, the maximum lockup period is four years. 67% of them actually do lock up for that long on an average. What do you think it's for Polkadot? A similar vote escrow system. It's again a shocking 4% locking up for a maximum duration of 224 days. What is the other sign you see is that this behavior, perhaps the underlying assumption is the financial incentives and how the whole incentive governance mechanism is playing out together. We also went deeper. We said, who are these voters that are locking in longer? Are these whales? Are these large token holders? We found a very interesting insight both in Curve and Polkadot where 93% of whales and 98% of sharks tend to lock up for 14 days or less. They tend to enjoy a sense of fluidity. They tend to enjoy a sense of flexibility with their lockup tokens. We saw shrimps, on the other hand, locking up much longer. And when you design your governance system, this is going to play a key role. Who are your token holders? What's their demographics? How are you going to design your lockups? And who's likely going to lock up for longer? It's going to play a pretty huge role in the way you design that. For more on the governance research paper, it's full of insights. You have that QR code, feel free to scan it. This is one of my favorites, good governance is obvious, but great governance is transparent. So many, like over the last three years of being in governance, I've had multiple people tell me, I don't understand what to vote. And who's keeping track of what to vote? Well, we've introduced something called as transparency reports, where every multi-isig that's apparently taking decision is supposed to put out their rationale behind it. And so you can read a transparency report. It's designed for even non-technical folks to really understand what's happening and exit the system if you choose that that upgrade is not safe for you or one that you don't like. Almost every governance team I work in, this is a mandatory introduction and we made it very easy for folks to generate a transparency report. My time's up, but you can read more about transparency reports as well. What I'm going to do is I'm just going to jump through the final one, which is the conditional voting power, DK. So the concept's really simple. Your voting power DKs with time but based on your participation and there's an interesting research on that as well. But yes, thank you so much everyone for taking the time and I hope this helps. All right, so... Okay, so... Do we have any questions for Tanisha? We can do maybe a round of passing the mic if anyone has questions. Yeah, we do have one over there. We do have one question at the back. Yeah. Hello. Do you mention the difference between Polkadot and Curve? And how Curve has, like, higher votes just because of the rewards or, like, incentives? What sort of incentives are at play in there, or what incentives you think might make sense for most DAOs? That's a great question. It depends on what the DAO focuses on. There isn't like a one-size-fits-all answer. So if it's like Curve or any DAO that's focusing on liquidity, having APYs for staking that's combined with governance where you have like an underlying staking mechanism with vote escrow and giving APIs for that crypto economic guarantees makes a lot of sense. But for DAOs that's not focusing on staking and focusing on engagement, having very interesting ways of distributing funds based on the level of engagement like for a gaming DAO makes a lot more sense than just vote escrow or staking. So it's really what the DAO is seeking at the end of the day. All right, thank you. And actually, Tanisha, here's a live question. What do you use to gather this data? It's mostly on chain in the sense that a lot of these data points are already there. So when your Curve and Polkadot already have it on chain. So you take all the wallet addresses. We used Arkham data to also identify some of these wallets and who they belong to, to measure the level of centralization. We used Arkham data to also identify some of these wallets and who they belong to, to measure the level of centralization. But I hope that answered your question. Hi. My question is more maybe on privacy and still managing engagement. Do you see valuable like using TK for enhancing privacy in managing the proposal and still giving the confidence of user that will not be blackfired maybe for any exposure? Yeah, that's a great question. So maybe not in proposal creation. I think privacy is, in my opinion, best suited to delegations. So I was talking about this to somebody yesterday. Let's say that I delegate to you and I want to undelegate, right?",
"eventId": "devcon-7",
- "slot_start": 1731569700000,
- "slot_end": 1731570600000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1JN8fHkrJUSmMwQcFE6vbbWGfFN8h8mUo1A7pu-plAU8"
+ "slot_start": 1731489000000,
+ "slot_end": 1731489600000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1hyhPIjZoL4CayjCbBks0Dvhf-v1OSKN0dKkek0vNdSE",
+ "resources_slides": null,
+ "speakers": [
+ "tanisha-katara"
+ ]
},
"vector": [
0,
- 6,
0,
0,
0,
@@ -375368,6 +374594,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -376113,6 +375340,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -376148,6 +375376,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -376176,6 +375405,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -376198,11 +375428,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -376255,6 +375487,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -376363,6 +375596,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -376458,6 +375692,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -376658,19 +375894,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
0,
0,
2,
@@ -376678,6 +375901,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -376691,54 +375915,43 @@
},
{
"session": {
- "id": "governance-innovation-analysis-on-voter-behavior-in-blockchain-governance",
- "sourceId": "ZKNSAL",
- "title": "Governance Innovation: Analysis on Voter Behavior in Blockchain Governance",
- "description": "As the first comprehensive examination of voter behavior in Web3, the following research explores two significant blockchain ecosystems, Curve Finance and Polkadot, using a novel quantitative methodology to decompose and highlight governance patterns.\r\n\r\nThe presented analysis shows, among other findings, a significant influence of market conditions on voter tendencies, diverse patterns relating to voting power accumulation, and a potential effect of financial incentives on voter participation.",
- "track": "Coordination",
- "type": "Lightning Talk",
- "expertise": "Expert",
- "audience": "Product",
+ "id": "grandine-on-windows",
+ "sourceId": "SUTU99",
+ "title": "Grandine on Windows",
+ "description": "In this talk, the speaker will discuss the problems encountered in porting Grandine, an Ethereum consensus client, to Windows systems and the solutions from the perspectives of language, engineering, and cross-platform. The speaker found that these problems are common to the current Ethereum infrastructure based on the Rust language. Finally, the speaker will summarize and look forward to the development of Ethereum clients based on the Rust language, especially from the point of cross-platform.",
+ "track": "[CLS] EPF Day",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"tags": [
- "Permissionless",
- "Coordination",
- "Governance",
- "Decentralization",
- "Game Theory",
- "Tokenomics",
- "voting",
- "analytics",
- "Coordination",
- "Decentralization",
- "Game Theory",
- "Governance",
- "Permissionless",
- "Tokenomics"
+ "Best Practices",
+ "Core Protocol",
+ "Languages"
],
"keywords": [
- "Vote Escrow",
- "Funding Allocation",
- "Voter Analytics"
+ "Rust",
+ "Client",
+ "Engineering"
],
- "duration": 535,
+ "duration": 759,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "wLw9Xvigdqs",
+ "sources_swarmHash": "3c373e0cffaa2ece62499d889302699c6414cc3b3651b30fc5031e2b0dd91bff",
+ "sources_youtubeId": "31hcxxdhzXs",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673476c59dbb7a90e1392576.vtt",
- "transcript_text": " Hello, everyone. Thank you so much for taking the time to join in. In this specific talk, we're going to cover about governance, and it will assume that you have a basic understanding of governance already. Another thing that this talk is going to do is drop a lot of QR codes because there's quite a few innovations I want to cover so you can go apply it in your worlds and the QR codes will help you dive deep into specific topics that you want to dive deep into. Let's start with innovation number one and this is so often like overlooked. Let's face it, right? Be it grants, be it governance, be it decision-making, the voter's perception is at the end of the day, your reality. And the user experience and governance is an area of innovation that's not very much focused on. This is where we have an interesting product we just launched, which kind of shows you how you can delegate in one of the simplest user experiences possible. You can select the percentage that you want to delegate. You exactly know what's your voting power going to look like, and then you delegate. And that's simple. And this is one area where we're trying to make user experience as less fragmented as possible. And if you'd like to read more about the thinking, the transparency, the ethos, the on-chain activities that went into designing a governance hub, I highly recommend scanning the QR code and jumping into it. Now, let's talk about not just the user experience. Let's go a little bit deeper, right? We did a research on how exactly voter behavior works out. We took two vote escrow systems. One, we took Polkadot. The other, we took Curve. Both of them require you to lock in your tokens and in return, you get a certain voting power. That voting power is decayed over a period of time. But there's one fundamental difference. Curve has a financial incentive mechanism to it. Every Thursday, you use your VE Curve tokens and you get APYs based on how the treasury allocates funds. Polkadot not necessarily has financial incentives attached to it. Now, you will see some very interesting insights. So in Curve, 65% of Curve is logged as Vcurve. And out of the 65% that's logged, an average of 38% is used for voting. What do you think that number would look like for Polkadot, one that doesn't have financial incentives? Well, 54% is locked in multiple Polkadot lockers. And it's, you know, a shockingly low 0.11% that's used for voting. And you can see how financial incentives play out a huge role in possibly this disparity. Let's go a bit deeper into another data point. In Curve, the maximum lockup period is four years. 67% of them actually do lock up for that long on an average. What do you think it's for Polkadot? A similar vote escrow system. It's again a shocking 4% locking up for a maximum duration of 224 days. What is the other sign you see is that this behavior, perhaps the underlying assumption is the financial incentives and how the whole incentive governance mechanism is playing out together. We also went deeper. We said, who are these voters that are locking in longer? Are these whales? Are these large token holders? We found a very interesting insight both in Curve and Polkadot where 93% of whales and 98% of sharks tend to lock up for 14 days or less. They tend to enjoy a sense of fluidity. They tend to enjoy a sense of flexibility with their lockup tokens. We saw shrimps, on the other hand, locking up much longer. And when you design your governance system, this is going to play a key role. Who are your token holders? What's their demographics? How are you going to design your lockups? And who's likely going to lock up for longer? It's going to play a pretty huge role in the way you design that. For more on the governance research paper, it's full of insights. You have that QR code, feel free to scan it. This is one of my favorites, good governance is obvious, but great governance is transparent. So many, like over the last three years of being in governance, I've had multiple people tell me, I don't understand what to vote. And who's keeping track of what to vote? Well, we've introduced something called as transparency reports, where every multi-isig that's apparently taking decision is supposed to put out their rationale behind it. And so you can read a transparency report. It's designed for even non-technical folks to really understand what's happening and exit the system if you choose that that upgrade is not safe for you or one that you don't like. Almost every governance team I work in, this is a mandatory introduction and we made it very easy for folks to generate a transparency report. My time's up, but you can read more about transparency reports as well. What I'm going to do is I'm just going to jump through the final one, which is the conditional voting power, DK. So the concept's really simple. Your voting power DKs with time but based on your participation and there's an interesting research on that as well. But yes, thank you so much everyone for taking the time and I hope this helps. All right, so... Okay, so... Do we have any questions for Tanisha? We can do maybe a round of passing the mic if anyone has questions. Yeah, we do have one over there. We do have one question at the back. Yeah. Hello. Do you mention the difference between Polkadot and Curve? And how Curve has, like, higher votes just because of the rewards or, like, incentives? What sort of incentives are at play in there, or what incentives you think might make sense for most DAOs? That's a great question. It depends on what the DAO focuses on. There isn't like a one-size-fits-all answer. So if it's like Curve or any DAO that's focusing on liquidity, having APYs for staking that's combined with governance where you have like an underlying staking mechanism with vote escrow and giving APIs for that crypto economic guarantees makes a lot of sense. But for DAOs that's not focusing on staking and focusing on engagement, having very interesting ways of distributing funds based on the level of engagement like for a gaming DAO makes a lot more sense than just vote escrow or staking. So it's really what the DAO is seeking at the end of the day. All right, thank you. And actually, Tanisha, here's a live question. What do you use to gather this data? It's mostly on chain in the sense that a lot of these data points are already there. So when your Curve and Polkadot already have it on chain. So you take all the wallet addresses. We used Arkham data to also identify some of these wallets and who they belong to, to measure the level of centralization. We used Arkham data to also identify some of these wallets and who they belong to, to measure the level of centralization. But I hope that answered your question. Hi. My question is more maybe on privacy and still managing engagement. Do you see valuable like using TK for enhancing privacy in managing the proposal and still giving the confidence of user that will not be blackfired maybe for any exposure? Yeah, that's a great question. So maybe not in proposal creation. I think privacy is, in my opinion, best suited to delegations. So I was talking about this to somebody yesterday. Let's say that I delegate to you and I want to undelegate, right?",
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731489000000,
- "slot_end": 1731489600000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1hyhPIjZoL4CayjCbBks0Dvhf-v1OSKN0dKkek0vNdSE",
+ "slot_start": 1731481200000,
+ "slot_end": 1731482100000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1W4lSdrWzgMoJHrCdD1XG6PWUZq7B7QBp09iTEJj9lH0",
"resources_slides": null,
"speakers": [
- "tanisha-katara"
+ "jin-mingjian"
]
},
"vector": [
@@ -376753,11 +375966,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -377502,8 +376715,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -377512,6 +376723,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -377523,6 +376735,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -377538,7 +376751,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -377567,7 +376779,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -377596,7 +376807,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -377649,7 +376859,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -377759,7 +376968,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -377855,7 +377063,8 @@
0,
0,
0,
- 2,
+ 0,
+ 0,
0,
0,
0,
@@ -378060,10 +377269,11 @@
0,
2,
0,
+ 2,
+ 0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -378077,44 +377287,38 @@
},
{
"session": {
- "id": "grandine-on-windows",
- "sourceId": "SUTU99",
- "title": "Grandine on Windows",
- "description": "In this talk, the speaker will discuss the problems encountered in porting Grandine, an Ethereum consensus client, to Windows systems and the solutions from the perspectives of language, engineering, and cross-platform. The speaker found that these problems are common to the current Ethereum infrastructure based on the Rust language. Finally, the speaker will summarize and look forward to the development of Ethereum clients based on the Rust language, especially from the point of cross-platform.",
- "track": "[CLS] EPF Day",
+ "id": "grapheneos-a-brief-introduction-to-private-and-secure-android",
+ "sourceId": "QK3ZTL",
+ "title": "GrapheneOS: a brief introduction to private and secure Android",
+ "description": "Smartphones have become an essential part of our lives. The operating systems on smartphones act like a boundary layer between personal data and a plethora of untrusted code, but how easy is it to penetrate this boundary? We present GrapheneOS - the privacy and security-focused operating system developed as a non-profit open-source project. We will focus on some state-of-the-art GrapheneOS features such as low-level USB-C control, hardened memory allocator, and Sandboxed Google Play.",
+ "track": "Cypherpunk & Privacy",
"type": "Talk",
"expertise": "Beginner",
"audience": "Engineering",
"featured": false,
- "doNotRecord": false,
- "tags": [
- "Best Practices",
- "Core Protocol",
- "Languages"
- ],
+ "doNotRecord": true,
"keywords": [
- "Rust",
- "Client",
- "Engineering"
+ "Android"
+ ],
+ "tags": [
+ "Privacy",
+ "Security",
+ "Mobile",
+ "android",
+ "Mobile",
+ "Privacy",
+ "Security"
],
- "duration": 759,
"language": "en",
- "sources_swarmHash": "3c373e0cffaa2ece62499d889302699c6414cc3b3651b30fc5031e2b0dd91bff",
- "sources_youtubeId": "31hcxxdhzXs",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731481200000,
- "slot_end": 1731482100000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1W4lSdrWzgMoJHrCdD1XG6PWUZq7B7QBp09iTEJj9lH0",
- "resources_slides": null,
"speakers": [
- "jin-mingjian"
- ]
+ "hulk",
+ "maade"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731486000000,
+ "slot_end": 1731487800000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/105h0erRlmvaHWuoC8pgHHPTJmdK7CiGkTOcyb1Vs4Nw"
},
"vector": [
0,
@@ -378122,6 +377326,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -378132,7 +377337,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -378493,6 +377697,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -378865,7 +378070,7 @@
0,
0,
0,
- 0,
+ 6,
0,
0,
0,
@@ -378900,10 +378105,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -378966,8 +378167,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -378987,6 +378186,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -379231,6 +378431,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -379452,38 +378653,33 @@
},
{
"session": {
- "id": "grapheneos-a-brief-introduction-to-private-and-secure-android",
- "sourceId": "QK3ZTL",
- "title": "GrapheneOS: a brief introduction to private and secure Android",
- "description": "Smartphones have become an essential part of our lives. The operating systems on smartphones act like a boundary layer between personal data and a plethora of untrusted code, but how easy is it to penetrate this boundary? We present GrapheneOS - the privacy and security-focused operating system developed as a non-profit open-source project. We will focus on some state-of-the-art GrapheneOS features such as low-level USB-C control, hardened memory allocator, and Sandboxed Google Play.",
- "track": "Cypherpunk & Privacy",
+ "id": "growing-the-biomes-gdp-using-digital-matter-and-smart-items",
+ "sourceId": "AZCYRS",
+ "title": "Growing The Biomes GDP Using Digital Matter & Smart Items",
+ "description": "Biomes is growing the virtual world with the largest GDP. As a fully onchain 3D voxel world, every single action in Biomes -- mining, building, crafting, even moving -- is a transaction on the Redstone L2. \r\n\r\nWe will share stories how we're working to grow the GDP of Biomes, what is working and what isn't. We will also share examples and ideas for onchain smart items in the Biomes world enabled by smart contracts.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
"type": "Talk",
"expertise": "Beginner",
"audience": "Engineering",
"featured": false,
- "doNotRecord": true,
- "keywords": [
- "Android"
- ],
+ "doNotRecord": false,
+ "keywords": [],
"tags": [
- "Privacy",
- "Security",
- "Mobile",
- "android",
- "Mobile",
- "Privacy",
- "Security"
+ "Gaming",
+ "Autonomous World",
+ "Autonomous World",
+ "Gaming"
],
"language": "en",
"speakers": [
- "hulk",
- "maade"
+ "dhrumil-shah",
+ "dhvani-patel"
],
"eventId": "devcon-7",
- "slot_start": 1731486000000,
- "slot_end": 1731487800000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/105h0erRlmvaHWuoC8pgHHPTJmdK7CiGkTOcyb1Vs4Nw"
+ "slot_start": 1731567000000,
+ "slot_end": 1731568500000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/13_hK3uoJSZ6tt20JSY81twd2hzFWCOGFjUGmSMP9_R4"
},
"vector": [
0,
@@ -379491,8 +378687,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -379500,6 +378694,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -379563,6 +378758,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -379862,8 +379059,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -380238,7 +379433,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -380261,7 +379455,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -380348,13 +379541,14 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -380600,7 +379794,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -380821,11 +380014,11 @@
},
{
"session": {
- "id": "growing-the-biomes-gdp-using-digital-matter-and-smart-items",
- "sourceId": "AZCYRS",
- "title": "Growing The Biomes GDP Using Digital Matter & Smart Items",
- "description": "Biomes is growing the virtual world with the largest GDP. As a fully onchain 3D voxel world, every single action in Biomes -- mining, building, crafting, even moving -- is a transaction on the Redstone L2. \r\n\r\nWe will share stories how we're working to grow the GDP of Biomes, what is working and what isn't. We will also share examples and ideas for onchain smart items in the Biomes world enabled by smart contracts.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "id": "hacking-thai-beats-cities-and-dances",
+ "sourceId": "NM8B9E",
+ "title": "Hacking Thai Beats, Cities & Dances",
+ "description": "Can we inspire Thai builders to be more creative through hacking our own culture? Stories of an algorithmic Thai music festival in Thailand's oldest museum, an open-source hackathon to improve the city of Bangkok, an interactive art performance that blends algorithms with traditional Thai dance; and how you can build better builder communities by inter-disciplinary thinking.",
+ "track": "Real World Ethereum",
"type": "Talk",
"expertise": "Beginner",
"audience": "Engineering",
@@ -380833,29 +380026,21 @@
"doNotRecord": false,
"keywords": [],
"tags": [
- "Gaming",
- "Autonomous World",
- "Autonomous World",
- "Gaming"
+ "Art",
+ "FOSS",
+ "Live Coding"
],
"language": "en",
"speakers": [
- "dhrumil-shah",
- "dhvani-patel"
+ "phoomparin-mano"
],
"eventId": "devcon-7",
- "slot_start": 1731567000000,
- "slot_end": 1731568500000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/13_hK3uoJSZ6tt20JSY81twd2hzFWCOGFjUGmSMP9_R4"
+ "slot_start": 1731552900000,
+ "slot_end": 1731554100000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/16NvToD2NQxicsfxWktPRLuxSt7qrL73mCEcujVhk_i0"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -380926,25 +380111,6 @@
0,
0,
0,
- 6,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -381252,6 +380418,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -381712,8 +380879,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -381733,12 +380898,14 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -381956,6 +381123,27 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -382185,31 +381373,37 @@
},
{
"session": {
- "id": "hacking-thai-beats-cities-and-dances",
- "sourceId": "NM8B9E",
- "title": "Hacking Thai Beats, Cities & Dances",
- "description": "Can we inspire Thai builders to be more creative through hacking our own culture? Stories of an algorithmic Thai music festival in Thailand's oldest museum, an open-source hackathon to improve the city of Bangkok, an interactive art performance that blends algorithms with traditional Thai dance; and how you can build better builder communities by inter-disciplinary thinking.",
- "track": "Real World Ethereum",
+ "id": "hallucinated-servers-another-prog-crypto-chip",
+ "sourceId": "DYJ88A",
+ "title": "hallucinated servers another prog crypto chip",
+ "description": "An introduction to programmable cryptography, culminating in the dream of a \"hallucinated server\".",
+ "track": "Applied Cryptography",
"type": "Talk",
- "expertise": "Beginner",
+ "expertise": "Expert",
"audience": "Engineering",
"featured": false,
- "doNotRecord": false,
- "keywords": [],
+ "doNotRecord": true,
+ "keywords": [
+ "Cyprography",
+ "fhe",
+ "mpc"
+ ],
"tags": [
- "Art",
- "FOSS",
- "Live Coding"
+ "Cryptography",
+ "MPC",
+ "fhe",
+ "Cryptography",
+ "MPC"
],
"language": "en",
"speakers": [
- "phoomparin-mano"
+ "b-l"
],
"eventId": "devcon-7",
- "slot_start": 1731552900000,
- "slot_end": 1731554100000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/16NvToD2NQxicsfxWktPRLuxSt7qrL73mCEcujVhk_i0"
+ "slot_start": 1731556800000,
+ "slot_end": 1731558600000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1vVTMx-WFRYRYIkDhxt9cWeLavDtiXTRNFX6sO0Z4Nyo"
},
"vector": [
0,
@@ -382218,11 +381412,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -382974,6 +382168,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -383049,6 +382244,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -383072,14 +382268,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -383298,9 +382492,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -383326,6 +382517,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -383528,7 +382720,6 @@
0,
0,
2,
- 0,
2,
0,
0,
@@ -383547,37 +382738,37 @@
},
{
"session": {
- "id": "hallucinated-servers-another-prog-crypto-chip",
- "sourceId": "DYJ88A",
- "title": "hallucinated servers another prog crypto chip",
- "description": "An introduction to programmable cryptography, culminating in the dream of a \"hallucinated server\".",
- "track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Expert",
- "audience": "Engineering",
+ "id": "hardening-the-commons",
+ "sourceId": "BMTVJK",
+ "title": "Hardening the Commons",
+ "description": "A hands-on workshop for those interested in strengthening the capture resistance and general survivability of commons under their stewardship. This session will be a sequence of guided small group discussions that will flesh out the levels of a capability maturity model for how a commons resource, whether it is a blockchain or a city, can be gradually \"hardened\" by developing and maturing capabilities at material, philosophical, skill, social, and mission levels.",
+ "track": "Coordination",
+ "type": "Workshop",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
- "doNotRecord": true,
+ "doNotRecord": false,
"keywords": [
- "Cyprography",
- "fhe",
- "mpc"
+ "Impact",
+ "Commons",
+ "Adoption"
],
"tags": [
- "Cryptography",
- "MPC",
- "fhe",
- "Cryptography",
- "MPC"
+ "adoption",
+ "Censorship Resistance",
+ "Coordination",
+ "Solarpunk"
],
"language": "en",
"speakers": [
- "b-l"
+ "tim-beiko",
+ "venkatesh-rao"
],
"eventId": "devcon-7",
- "slot_start": 1731556800000,
- "slot_end": 1731558600000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1vVTMx-WFRYRYIkDhxt9cWeLavDtiXTRNFX6sO0Z4Nyo"
+ "slot_start": 1731486600000,
+ "slot_end": 1731497400000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/1gO904DKuSqj1sNQuLtbP57gbG3NphApmqMl4sI6azOs"
},
"vector": [
0,
@@ -383590,9 +382781,8 @@
0,
0,
0,
- 6,
- 0,
0,
+ 6,
0,
0,
0,
@@ -383766,6 +382956,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -384345,11 +383536,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -384421,7 +383607,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -384460,6 +383645,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -384482,14 +383668,17 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -384695,7 +383884,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -384895,8 +384083,6 @@
0,
0,
0,
- 0,
- 2,
2,
0,
0,
@@ -384904,6 +384090,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -384915,38 +384103,44 @@
},
{
"session": {
- "id": "hardening-mobile-operating-systems-for-enhanced-privacy",
- "sourceId": "DRKWGV",
- "title": "Hardening Mobile Operating Systems for Enhanced Privacy",
- "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "",
- "audience": "Engineering",
+ "id": "hardhat-3-preview-overhauled-and-rust-powered",
+ "sourceId": "QZYQYE",
+ "title": "Hardhat 3 Preview: Overhauled & Rust-Powered",
+ "description": "The Hardhat team has been working continuously over the past two years to redesign and rewrite Hardhat from the ground up, including a major migration to Rust. This talk will explore the problems and solutions that the upcoming release of Hardhat 3 will focus on: performance, Solidity tests, correct L2 network simulation, and a comprehensive deployment system.",
+ "track": "Developer Experience",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Hardhat",
+ "Solidity"
+ ],
+ "tags": [
+ "Developer Infrastructure",
+ "Tooling",
+ "DevEx",
+ "solidity",
+ "Developer Infrastructure",
+ "DevEx",
+ "Tooling"
+ ],
"language": "en",
"speakers": [
- "hulk",
- "maade"
+ "patricio-palladino"
],
"eventId": "devcon-7",
- "slot_start": 1731576600000,
- "slot_end": 1731577500000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1d2aapQyYzhgjOalAv-TJnnfo0oZ8Q-k-T4Lsok_kqbY"
+ "slot_start": 1731495600000,
+ "slot_end": 1731497400000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1XDRIhALcLD_91krtX14MMkCYoXRCN3nZ_oia1tIdaLw"
},
"vector": [
- 0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -385315,8 +384509,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -385325,6 +384517,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -385714,6 +384907,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -385722,6 +384916,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -385745,6 +384940,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -386053,6 +385249,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -386250,10 +385447,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
2,
@@ -386267,56 +385464,41 @@
0,
0,
0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "hardening-the-commons",
- "sourceId": "BMTVJK",
- "title": "Hardening the Commons",
- "description": "A hands-on workshop for those interested in strengthening the capture resistance and general survivability of commons under their stewardship. This session will be a sequence of guided small group discussions that will flesh out the levels of a capability maturity model for how a commons resource, whether it is a blockchain or a city, can be gradually \"hardened\" by developing and maturing capabilities at material, philosophical, skill, social, and mission levels.",
- "track": "Coordination",
- "type": "Workshop",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "hardware-security-from-sand-to-stone",
+ "sourceId": "UZDFEK",
+ "title": "Hardware Security: From Sand to Stone",
+ "description": "All software runs on hardware. The assumptions on which many of our systems rest are often shakier than we realise. This talk explores hardware security, its shortcomings and the path to a firmer foundation.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Impact",
- "Commons",
- "Adoption"
+ "TEE",
+ "Hardware Trojans"
],
"tags": [
- "adoption",
- "Censorship Resistance",
- "Coordination",
- "Solarpunk"
+ "Decentralization",
+ "Hardware wallets",
+ "Security"
],
"language": "en",
"speakers": [
- "tim-beiko",
- "venkatesh-rao"
+ "quintus-kilbourn"
],
"eventId": "devcon-7",
- "slot_start": 1731486600000,
- "slot_end": 1731497400000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/1gO904DKuSqj1sNQuLtbP57gbG3NphApmqMl4sI6azOs"
+ "slot_start": 1731576000000,
+ "slot_end": 1731576600000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1wcISJi-Q9aswEj-3R97yb_9jp5DN6P_38XsaGdEq3B4"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
6,
0,
@@ -386493,18 +385675,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -386687,7 +385857,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -386711,6 +385880,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -387078,6 +386248,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -387179,12 +386350,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -387207,17 +386378,14 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -387416,6 +386584,19 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -387622,7 +386803,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -387633,6 +386813,15 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -387642,50 +386831,37 @@
},
{
"session": {
- "id": "hardhat-3-preview-overhauled-and-rust-powered",
- "sourceId": "QZYQYE",
- "title": "Hardhat 3 Preview: Overhauled & Rust-Powered",
- "description": "The Hardhat team has been working continuously over the past two years to redesign and rewrite Hardhat from the ground up, including a major migration to Rust. This talk will explore the problems and solutions that the upcoming release of Hardhat 3 will focus on: performance, Solidity tests, correct L2 network simulation, and a comprehensive deployment system.",
- "track": "Developer Experience",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Developer",
+ "id": "harry-p",
+ "sourceId": "LXJJDW",
+ "title": "Harry P",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Hardhat",
- "Solidity"
- ],
- "tags": [
- "Developer Infrastructure",
- "Tooling",
- "DevEx",
- "solidity",
- "Developer Infrastructure",
- "DevEx",
- "Tooling"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "patricio-palladino"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731495600000,
- "slot_end": 1731497400000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1XDRIhALcLD_91krtX14MMkCYoXRCN3nZ_oia1tIdaLw"
+ "slot_start": 1731488400000,
+ "slot_end": 1731492000000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1wNma7KIt9CoI1JayWZB-MIf47ge7DGlMJ3Ev9Il3pdE"
},
"vector": [
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -388057,7 +387233,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -388449,7 +387624,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -388458,7 +387632,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -388482,7 +387655,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -388792,7 +387964,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -388989,10 +388160,10 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
0,
0,
2,
@@ -389006,42 +388177,45 @@
0,
0,
0,
+ 0,
+ 0,
0
]
},
{
"session": {
- "id": "hardware-security-from-sand-to-stone",
- "sourceId": "UZDFEK",
- "title": "Hardware Security: From Sand to Stone",
- "description": "All software runs on hardware. The assumptions on which many of our systems rest are often shakier than we realise. This talk explores hardware security, its shortcomings and the path to a firmer foundation.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
+ "id": "hevm-or-how-i-learned-to-stop-worrying-and-love-the-symbolic-execution",
+ "sourceId": "YQPADR",
+ "title": "hevm or: How I Learned to Stop Worrying and Love the Symbolic Execution",
+ "description": "hevm is a symbolic execution engine for the EVM that can prove safety properties for EVM bytecode or verify semantic equivalence between two bytecode objects. It exposes a user-friendly API in Solidity that allows you to define symbolic tests using almost exactly the same syntax as usual unit tests.\r\n\r\nIn this talk, we'll present hevm, what it's useful for, and when and how to use it to help secure your digital contracts.",
+ "track": "Security",
+ "type": "Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "TEE",
- "Hardware Trojans"
+ "Symbolic Execution",
+ "EVM"
],
"tags": [
- "Decentralization",
- "Hardware wallets",
+ "Security",
+ "Fuzzing",
+ "EVM",
+ "Fuzzing",
"Security"
],
"language": "en",
"speakers": [
- "quintus-kilbourn"
+ "mate-soos"
],
"eventId": "devcon-7",
- "slot_start": 1731576000000,
- "slot_end": 1731576600000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1wcISJi-Q9aswEj-3R97yb_9jp5DN6P_38XsaGdEq3B4"
+ "slot_start": 1731560400000,
+ "slot_end": 1731562200000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1zbKn6alKaFJ7AHUN8resSuZmq-0n4W0JbxXcZGI9Cq8"
},
"vector": [
- 0,
6,
0,
0,
@@ -389423,10 +388597,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -389794,6 +388966,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -389895,7 +389068,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -390000,6 +389172,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -390130,7 +389303,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -390376,25 +389548,41 @@
},
{
"session": {
- "id": "harry-p",
- "sourceId": "LXJJDW",
- "title": "Harry P",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
- "audience": "Engineering",
+ "id": "how-crypto-is-used-in-africa-today-hear-from-leading-builders",
+ "sourceId": "RKR9EC",
+ "title": "How crypto is used in Africa today? Hear from leading builders",
+ "description": "How are Africans using crypto at scale, and what has been the impact on society? Last year Africa saw close to $120B onchain transactions, and 10%-20% of major countries' populations used crypto. \r\n\r\nWhat problems are the top African founders solving for retail and businesses? What are the technical + non-technical friction points they face in building for the fastest growing markets in the world?\r\n\r\nHear African founders share lessons, nuances, and user behavior from the front lines.",
+ "track": "Real World Ethereum",
+ "type": "Panel",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Mass adoption",
+ "payment",
+ "P2P"
+ ],
+ "tags": [
+ "Use Cases",
+ "Remittance",
+ "Ethereum for Good",
+ "p2p",
+ "Ethereum for Good",
+ "Remittance",
+ "Use Cases"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "yoseph-ayele",
+ "yele-bademosi",
+ "david-nandwa"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731488400000,
- "slot_end": 1731492000000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1wNma7KIt9CoI1JayWZB-MIf47ge7DGlMJ3Ev9Il3pdE"
+ "slot_start": 1731650400000,
+ "slot_end": 1731654000000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1-iuDsB5_A6OL9P-2eTEkEzeWPAc_YK9UNsVLwT5Pf6A"
},
"vector": [
0,
@@ -390403,9 +389591,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -390783,6 +389968,9 @@
0,
0,
0,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -391225,6 +390413,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -391271,6 +390460,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -391442,6 +390632,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -391507,12 +390698,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -391714,12 +390900,11 @@
2,
0,
0,
- 2,
- 0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -391732,58 +390917,46 @@
},
{
"session": {
- "id": "hevm-or-how-i-learned-to-stop-worrying-and-love-the-symbolic-execution",
- "sourceId": "YQPADR",
- "title": "hevm or: How I Learned to Stop Worrying and Love the Symbolic Execution",
- "description": "hevm is a symbolic execution engine for the EVM that can prove safety properties for EVM bytecode or verify semantic equivalence between two bytecode objects. It exposes a user-friendly API in Solidity that allows you to define symbolic tests using almost exactly the same syntax as usual unit tests.\r\n\r\nIn this talk, we'll present hevm, what it's useful for, and when and how to use it to help secure your digital contracts.",
- "track": "Security",
+ "id": "how-crypto-solves-real-world-mev",
+ "sourceId": "WQBBFR",
+ "title": "How Crypto Solves Real World MEV",
+ "description": "This session will discuss \"real world\" MEV applications of crypto. I highlight three examples in particular:\r\n\r\n-Event ticketing, a multi-billion dollar market place where ZK Proofs and Trusted Execution Environments have a promising role to play. \r\n-Negotiations using crypto-enforceable non-disclosure agreements (joint design with Andrew Miller)\r\n-And finally, *maximizing* Web2 MEV by allowing trustless account permissioning, e.g. on x.com\r\n\r\nEach example has a spec and a working demo with code.",
+ "track": "Cryptoeconomics",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Symbolic Execution",
- "EVM"
+ "Trusted",
+ "Execution",
+ "Environments"
],
"tags": [
- "Security",
- "Fuzzing",
- "EVM",
- "Fuzzing",
- "Security"
+ "Use cases of cryptography",
+ "Use Cases",
+ "Environment",
+ "Mechanism design",
+ "trusted",
+ "execution",
+ "Mechanism design",
+ "Use Cases",
+ "Use cases of cryptography"
],
"language": "en",
"speakers": [
- "mate-soos"
+ "matt-stephenson"
],
"eventId": "devcon-7",
- "slot_start": 1731560400000,
- "slot_end": 1731562200000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1zbKn6alKaFJ7AHUN8resSuZmq-0n4W0JbxXcZGI9Cq8"
+ "slot_start": 1731643200000,
+ "slot_end": 1731645000000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/18AqH-uxxVvfWaJGEmHZyGujUgl3X-sss6n89RtybhTg"
},
"vector": [
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -392147,7 +391320,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -392168,6 +391340,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -392516,8 +391689,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -392539,6 +391710,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -392559,6 +391731,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -392609,6 +391782,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -392701,6 +391875,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -392893,6 +392068,21 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -393074,18 +392264,15 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
2,
0,
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -393099,50 +392286,48 @@
},
{
"session": {
- "id": "how-crypto-is-used-in-africa-today-hear-from-leading-builders",
- "sourceId": "RKR9EC",
- "title": "How crypto is used in Africa today? Hear from leading builders",
- "description": "How are Africans using crypto at scale, and what has been the impact on society? Last year Africa saw close to $120B onchain transactions, and 10%-20% of major countries' populations used crypto. \r\n\r\nWhat problems are the top African founders solving for retail and businesses? What are the technical + non-technical friction points they face in building for the fastest growing markets in the world?\r\n\r\nHear African founders share lessons, nuances, and user behavior from the front lines.",
- "track": "Real World Ethereum",
- "type": "Panel",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "how-hardhat-3-will-ensure-precise-simulation-for-l2s-using-edr",
+ "sourceId": "G7AHS9",
+ "title": "How Hardhat 3 will ensure precise simulation for L2s using EDR",
+ "description": "As the Ethereum ecosystem shifts towards L2 solutions, developers encounter new challenges in maintaining consistency and efficiency across different chains.\r\n\r\nHardhat is powered by EDR, a reusable Ethereum Development Runtime implementation to build developer tools. This talk will show how EDR's support for L2s in Hardhat 3 will streamline the development process, improve testing accuracy, and enhance the overall developer experience.",
+ "track": "Developer Experience",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Mass adoption",
- "payment",
- "P2P"
+ "EVM",
+ "Hardhat",
+ "Optimism"
],
"tags": [
- "Use Cases",
- "Remittance",
- "Ethereum for Good",
- "p2p",
- "Ethereum for Good",
- "Remittance",
- "Use Cases"
+ "Layer 2s",
+ "Tooling",
+ "DevEx",
+ "optimism",
+ "DevEx",
+ "Layer 2s",
+ "Tooling"
],
"language": "en",
"speakers": [
- "yoseph-ayele",
- "yele-bademosi",
- "david-nandwa"
+ "wodann"
],
"eventId": "devcon-7",
- "slot_start": 1731650400000,
- "slot_end": 1731654000000,
+ "slot_start": 1731582000000,
+ "slot_end": 1731583800000,
"slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1-iuDsB5_A6OL9P-2eTEkEzeWPAc_YK9UNsVLwT5Pf6A"
+ "resources_presentation": "https://docs.google.com/presentation/d/19L7dj6AAC2bhxtksWRYlrJuOv3Xc6aF5iQmk5DGFVbA"
},
"vector": [
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -393520,12 +392705,10 @@
0,
0,
0,
- 6,
- 6,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -393908,6 +393091,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -393916,6 +393100,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -393951,6 +393136,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -393967,7 +393153,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -394014,7 +393199,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -394140,6 +393324,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -394187,7 +393372,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -394253,7 +393437,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -394448,6 +393631,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -394458,8 +393642,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -394471,45 +393653,43 @@
},
{
"session": {
- "id": "how-crypto-solves-real-world-mev",
- "sourceId": "WQBBFR",
- "title": "How Crypto Solves Real World MEV",
- "description": "This session will discuss \"real world\" MEV applications of crypto. I highlight three examples in particular:\r\n\r\n-Event ticketing, a multi-billion dollar market place where ZK Proofs and Trusted Execution Environments have a promising role to play. \r\n-Negotiations using crypto-enforceable non-disclosure agreements (joint design with Andrew Miller)\r\n-And finally, *maximizing* Web2 MEV by allowing trustless account permissioning, e.g. on x.com\r\n\r\nEach example has a spec and a working demo with code.",
- "track": "Cryptoeconomics",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "id": "how-i-audit",
+ "sourceId": "3NRXP9",
+ "title": "How I Audit",
+ "description": "Dom, a former security researcher at Trail of Bits, is going to give a peek of what it's like to be an auditor in 2024. Some of the techniques and tools discussed:\r\n\r\n* How to prepare for an audit?\r\n* How to hand over the resources?\r\n* What is the first thing auditors do?\r\n* How to communicate with auditors?\r\n* How I use the following tools, and their evaluation:\r\n * Codebase visualization with Wake and Neovim\r\n * Static analysis tools\r\n * Fuzzing (and debugging)\r\n * Manual review",
+ "track": "Security",
+ "type": "Workshop",
+ "expertise": "Expert",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Trusted",
- "Execution",
- "Environments"
+ "Solidity",
+ "Frameworks",
+ "Program analysis",
+ "Static Analysis"
],
"tags": [
- "Use cases of cryptography",
- "Use Cases",
- "Environment",
- "Mechanism design",
- "trusted",
- "execution",
- "Mechanism design",
- "Use Cases",
- "Use cases of cryptography"
+ "Tooling",
+ "Security",
+ "Auditing",
+ "analysis",
+ "static",
+ "Auditing",
+ "Security",
+ "Tooling"
],
"language": "en",
"speakers": [
- "matt-stephenson"
+ "dominik-teiml"
],
"eventId": "devcon-7",
- "slot_start": 1731643200000,
- "slot_end": 1731645000000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/18AqH-uxxVvfWaJGEmHZyGujUgl3X-sss6n89RtybhTg"
+ "slot_start": 1731646800000,
+ "slot_end": 1731652200000,
+ "slot_roomId": "classroom-b",
+ "resources_presentation": "https://docs.google.com/presentation/d/1cJm-toCXN2UU4rbGe04A5r8Ki0Mu2kurnbC7eBJWsbQ"
},
"vector": [
- 0,
- 0,
6,
0,
0,
@@ -394895,10 +394075,10 @@
0,
0,
0,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -395259,15 +394439,16 @@
0,
0,
0,
+ 6,
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -395279,6 +394460,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -395288,7 +394470,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -395339,7 +394520,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -395411,6 +394591,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -395432,7 +394613,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -395455,7 +394635,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -395821,12 +395000,12 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
2,
+ 2,
+ 0,
0,
0,
0,
@@ -395843,44 +395022,42 @@
},
{
"session": {
- "id": "how-hardhat-3-will-ensure-precise-simulation-for-l2s-using-edr",
- "sourceId": "G7AHS9",
- "title": "How Hardhat 3 will ensure precise simulation for L2s using EDR",
- "description": "As the Ethereum ecosystem shifts towards L2 solutions, developers encounter new challenges in maintaining consistency and efficiency across different chains.\r\n\r\nHardhat is powered by EDR, a reusable Ethereum Development Runtime implementation to build developer tools. This talk will show how EDR's support for L2s in Hardhat 3 will streamline the development process, improve testing accuracy, and enhance the overall developer experience.",
- "track": "Developer Experience",
+ "id": "how-long-non-finality-could-kill-ethereum",
+ "sourceId": "U9E7PD",
+ "title": "How long non-finality could kill Ethereum",
+ "description": "After the merge, Ethereum has a finality gadget to provide an economic assurance that transactions will never be reverted. When 2/3 of the validator set are online and agree, we finalize. Otherwise, we enter a period of non-finality which can be very long, up to a few weeks. Long non-finality has never happened in Ethereum's history and could trigger a cascade of failures that will kill liveness. How can we harden the network against this? How high are the stakes?",
+ "track": "Core Protocol",
"type": "Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "EVM",
- "Hardhat",
- "Optimism"
+ "-"
],
"tags": [
- "Layer 2s",
- "Tooling",
- "DevEx",
- "optimism",
- "DevEx",
- "Layer 2s",
- "Tooling"
+ "Consensus",
+ "Decentralization",
+ "Security",
+ "Consensus",
+ "Decentralization",
+ "Security"
],
"language": "en",
"speakers": [
- "wodann"
+ "dapplion"
],
"eventId": "devcon-7",
- "slot_start": 1731582000000,
- "slot_end": 1731583800000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/19L7dj6AAC2bhxtksWRYlrJuOv3Xc6aF5iQmk5DGFVbA"
+ "slot_start": 1731568200000,
+ "slot_end": 1731570000000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ALLMSUfx7xTKyChAX-LGEzcu_42YB7z9HKrLLPQ0-cc"
},
"vector": [
0,
0,
0,
+ 0,
6,
0,
0,
@@ -396626,10 +395803,12 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -396651,16 +395830,11 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -396696,7 +395870,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -396732,6 +395905,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -396885,7 +396059,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -397213,48 +396386,48 @@
},
{
"session": {
- "id": "how-i-audit",
- "sourceId": "3NRXP9",
- "title": "How I Audit",
- "description": "Dom, a former security researcher at Trail of Bits, is going to give a peek of what it's like to be an auditor in 2024. Some of the techniques and tools discussed:\r\n\r\n* How to prepare for an audit?\r\n* How to hand over the resources?\r\n* What is the first thing auditors do?\r\n* How to communicate with auditors?\r\n* How I use the following tools, and their evaluation:\r\n * Codebase visualization with Wake and Neovim\r\n * Static analysis tools\r\n * Fuzzing (and debugging)\r\n * Manual review",
- "track": "Security",
- "type": "Workshop",
- "expertise": "Expert",
- "audience": "Engineering",
+ "id": "how-model-checking-can-help-build-trust-in-the-design-of-distributed-protocols-like-single-slot-finality",
+ "sourceId": "89M7ME",
+ "title": "How model checking can help build trust in the design of distributed protocols like Single Slot Finality",
+ "description": "Ethereum is a lively place for developing distributed protocols. Getting a distributed protocol right is a notoriously difficult task. When it comes to developing the Ethereum CL, the community follows two pragmatic approaches: Writing pen & paper proofs and writing executable specs in Python. We show how model checking can confirm our intuition about the behavior of consensus protocols or disprove it. We do so by applying our method to one of the recently proposed Single Slot Finality protocols",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Solidity",
- "Frameworks",
- "Program analysis",
- "Static Analysis"
+ "model checking",
+ "TLA+",
+ "Apalache"
],
"tags": [
- "Tooling",
- "Security",
- "Auditing",
- "analysis",
- "static",
- "Auditing",
- "Security",
- "Tooling"
+ "Consensus",
+ "Protocol Design",
+ "Formal Verification",
+ "apalache",
+ "Consensus",
+ "Formal Verification",
+ "Protocol Design"
],
"language": "en",
"speakers": [
- "dominik-teiml"
+ "igor-konnov",
+ "thanh-hai-tran"
],
"eventId": "devcon-7",
- "slot_start": 1731646800000,
- "slot_end": 1731652200000,
- "slot_roomId": "classroom-b",
- "resources_presentation": "https://docs.google.com/presentation/d/1cJm-toCXN2UU4rbGe04A5r8Ki0Mu2kurnbC7eBJWsbQ"
+ "slot_start": 1731641400000,
+ "slot_end": 1731642000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Xd-R_4o4lETYbwbQd-AVQI0TPre950m6puMNTO8psWk"
},
"vector": [
- 6,
0,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -397406,6 +396579,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -397604,6 +396778,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -397639,7 +396814,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -398006,7 +397180,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -398023,7 +397196,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -398045,6 +397217,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -398154,11 +397327,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -398200,6 +397368,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -398563,12 +397732,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
- 2,
0,
+ 2,
0,
0,
0,
@@ -398585,40 +397754,41 @@
},
{
"session": {
- "id": "how-long-non-finality-could-kill-ethereum",
- "sourceId": "U9E7PD",
- "title": "How long non-finality could kill Ethereum",
- "description": "After the merge, Ethereum has a finality gadget to provide an economic assurance that transactions will never be reverted. When 2/3 of the validator set are online and agree, we finalize. Otherwise, we enter a period of non-finality which can be very long, up to a few weeks. Long non-finality has never happened in Ethereum's history and could trigger a cascade of failures that will kill liveness. How can we harden the network against this? How high are the stakes?",
- "track": "Core Protocol",
+ "id": "how-much-security-does-your-restaking-protocol-really-need",
+ "sourceId": "QDDV9C",
+ "title": "How much security does your restaking protocol really need?",
+ "description": "Restaking protocols have aggregated millions of ETH with the hope of securing new infrastructure on Ethereum. These services, such as ZK provers and oracles, require restaking ETH to enforce custom slashing rules. But how much ETH do these services need? And how much risk do these services place on Ethereum L1? We will formulate a mathematical model for answering these questions and present an empirical analysis of cascading risks from restaking services to Ethereum, with a positive outlook!",
+ "track": "Cryptoeconomics",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Expert",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "-"
+ "Matching Markets",
+ "Proof of Stake"
],
"tags": [
- "Consensus",
- "Decentralization",
- "Security",
- "Consensus",
- "Decentralization",
- "Security"
+ "Staking",
+ "Censorship Resistance",
+ "Economics",
+ "Restaking",
+ "proof-of",
+ "Censorship Resistance",
+ "Economics",
+ "Restaking"
],
"language": "en",
"speakers": [
- "dapplion"
+ "tarun-chitra"
],
"eventId": "devcon-7",
- "slot_start": 1731568200000,
- "slot_end": 1731570000000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1ALLMSUfx7xTKyChAX-LGEzcu_42YB7z9HKrLLPQ0-cc"
+ "slot_start": 1731556800000,
+ "slot_end": 1731558600000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1pXSBtge-cUH6xweP8_EkxdNV7HFwwguB4oabzfh2UJ4"
},
"vector": [
- 0,
- 0,
0,
0,
6,
@@ -399007,9 +398177,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -399369,12 +398539,10 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -399405,6 +398573,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -399471,7 +398640,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -399499,6 +398667,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -399517,6 +398686,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -399736,6 +398906,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -399932,8 +399104,6 @@
0,
2,
0,
- 0,
- 0,
2,
0,
0,
@@ -399946,53 +399116,50 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "how-model-checking-can-help-build-trust-in-the-design-of-distributed-protocols-like-single-slot-finality",
- "sourceId": "89M7ME",
- "title": "How model checking can help build trust in the design of distributed protocols like Single Slot Finality",
- "description": "Ethereum is a lively place for developing distributed protocols. Getting a distributed protocol right is a notoriously difficult task. When it comes to developing the Ethereum CL, the community follows two pragmatic approaches: Writing pen & paper proofs and writing executable specs in Python. We show how model checking can confirm our intuition about the behavior of consensus protocols or disprove it. We do so by applying our method to one of the recently proposed Single Slot Finality protocols",
- "track": "Core Protocol",
+ "id": "how-to-audit-smart-contract-languages-brief-intro",
+ "sourceId": "HMYRTU",
+ "title": "How to Audit Smart Contract Languages: Brief Intro",
+ "description": "In this talk, we’ll dive into the unique challenges and considerations when auditing a smart contract language, as opposed to auditing individual smart contracts. We’ll cover:\r\n\r\n- Things to Look For: Key aspects of a smart contract language that need review.\r\n- Mindset Difference: Shifting from a contract-centric to a language-centric perspective, focusing on broader systemic issues rather than isolated contract logic.",
+ "track": "Security",
"type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "model checking",
- "TLA+",
- "Apalache"
+ "Language",
+ "Security"
],
"tags": [
- "Consensus",
- "Protocol Design",
- "Formal Verification",
- "apalache",
- "Consensus",
- "Formal Verification",
- "Protocol Design"
+ "Languages",
+ "Security",
+ "Auditing",
+ "language",
+ "Auditing",
+ "Languages",
+ "Security"
],
"language": "en",
"speakers": [
- "igor-konnov",
- "thanh-hai-tran"
+ "nicolas-garcia"
],
"eventId": "devcon-7",
- "slot_start": 1731641400000,
- "slot_end": 1731642000000,
+ "slot_start": 1731655800000,
+ "slot_end": 1731656400000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Xd-R_4o4lETYbwbQd-AVQI0TPre950m6puMNTO8psWk"
+ "resources_presentation": "https://docs.google.com/presentation/d/1r4V8Ln3v53MiKcUcMCQ8Cs-LG2p8VboqrQ6RHXvL-DY"
},
"vector": [
+ 6,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -400146,7 +399313,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -400345,7 +399511,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -400381,6 +399546,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -400738,6 +399904,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -400745,7 +399912,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -400786,7 +399952,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -400836,6 +400001,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -400890,6 +400056,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -400937,7 +400104,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -401299,8 +400465,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -401323,45 +400487,44 @@
},
{
"session": {
- "id": "how-much-security-does-your-restaking-protocol-really-need",
- "sourceId": "QDDV9C",
- "title": "How much security does your restaking protocol really need?",
- "description": "Restaking protocols have aggregated millions of ETH with the hope of securing new infrastructure on Ethereum. These services, such as ZK provers and oracles, require restaking ETH to enforce custom slashing rules. But how much ETH do these services need? And how much risk do these services place on Ethereum L1? We will formulate a mathematical model for answering these questions and present an empirical analysis of cascading risks from restaking services to Ethereum, with a positive outlook!",
- "track": "Cryptoeconomics",
+ "id": "how-to-coordinate-an-epistemic-revolution",
+ "sourceId": "DNJMER",
+ "title": "How to coordinate an epistemic revolution",
+ "description": "Amid widespread misinformation, division, and fractured consensus, we face an epistemic crisis. This talk unifies learning and governance theory, organizational design, social consensus tools, AI, and prediction markets. We will explore how DAOs and Ethereum can serve as decentralized platforms for collective intelligence and planetary-scale problem-solving, guiding us toward an epistemic revolution at this critical time.",
+ "track": "Coordination",
"type": "Talk",
- "expertise": "Expert",
+ "expertise": "Beginner",
"audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Matching Markets",
- "Proof of Stake"
+ "Semantic Governance",
+ "Identity",
+ "Citizens Assembly"
],
"tags": [
- "Staking",
- "Censorship Resistance",
- "Economics",
- "Restaking",
- "proof-of",
- "Censorship Resistance",
- "Economics",
- "Restaking"
+ "Consensus",
+ "Quadratic Voting",
+ "Collective Intelligence",
+ "citizens",
+ "assembly",
+ "Collective Intelligence",
+ "Consensus",
+ "Quadratic Voting"
],
"language": "en",
"speakers": [
- "tarun-chitra"
+ "nick-almond"
],
"eventId": "devcon-7",
- "slot_start": 1731556800000,
- "slot_end": 1731558600000,
+ "slot_start": 1731643800000,
+ "slot_end": 1731645600000,
"slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1pXSBtge-cUH6xweP8_EkxdNV7HFwwguB4oabzfh2UJ4"
+ "resources_presentation": "https://docs.google.com/presentation/d/1sq5KPHZmGsWxfhQtVwIBL6Wm8XGy-QAB5wFPQck9lO4"
},
"vector": [
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -401371,6 +400534,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -401749,9 +400913,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -402113,6 +401277,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -402141,11 +401306,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -402239,7 +401404,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -402258,7 +401422,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -402318,6 +401481,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -402671,11 +401835,9 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
+ 0,
2,
0,
0,
@@ -402693,46 +401855,48 @@
},
{
"session": {
- "id": "how-to-audit-smart-contract-languages-brief-intro",
- "sourceId": "HMYRTU",
- "title": "How to Audit Smart Contract Languages: Brief Intro",
- "description": "In this talk, we’ll dive into the unique challenges and considerations when auditing a smart contract language, as opposed to auditing individual smart contracts. We’ll cover:\r\n\r\n- Things to Look For: Key aspects of a smart contract language that need review.\r\n- Mindset Difference: Shifting from a contract-centric to a language-centric perspective, focusing on broader systemic issues rather than isolated contract logic.",
- "track": "Security",
- "type": "Lightning Talk",
+ "id": "how-to-destroy-a-network-offboarding-the-mainstream",
+ "sourceId": "XNCFRL",
+ "title": "How To Destroy A Network: Offboarding The Mainstream",
+ "description": "Crafting Ethereum into a setting (both technically and reputationally) where The Institutions feel comfortable participating in it at scale has been the life work of hundreds of people over the last nine years. And yet, for our success, many feel that the victory has come at a cost too heavy to bear: our losing focus as to why we built the global computer in the first place. If you feel the same way, join me for a brief exploration of what would need to happen for us to cut the cord.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Language",
- "Security"
+ "Values"
],
"tags": [
- "Languages",
- "Security",
- "Auditing",
- "language",
- "Auditing",
- "Languages",
- "Security"
+ "Network State",
+ "Privacy",
+ "Anonymity",
+ "Digital Sovereignty",
+ "value",
+ "Anonymity",
+ "Digital Sovereignty",
+ "Network State",
+ "Privacy"
],
"language": "en",
"speakers": [
- "nicolas-garcia"
+ "laurence-day"
],
"eventId": "devcon-7",
- "slot_start": 1731655800000,
- "slot_end": 1731656400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1r4V8Ln3v53MiKcUcMCQ8Cs-LG2p8VboqrQ6RHXvL-DY"
+ "slot_start": 1731484200000,
+ "slot_end": 1731486000000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1mVbPl6HPZouYDklCGe84dKqjwtSkE7VTKOYNdWU6URc"
},
"vector": [
- 6,
0,
0,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -403479,7 +402643,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -403502,6 +402665,20 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -403509,8 +402686,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -403631,7 +402810,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -403814,45 +402992,27 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
0,
0,
0,
@@ -404045,11 +403205,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -404062,40 +403222,42 @@
},
{
"session": {
- "id": "how-to-coordinate-an-epistemic-revolution",
- "sourceId": "DNJMER",
- "title": "How to coordinate an epistemic revolution",
- "description": "Amid widespread misinformation, division, and fractured consensus, we face an epistemic crisis. This talk unifies learning and governance theory, organizational design, social consensus tools, AI, and prediction markets. We will explore how DAOs and Ethereum can serve as decentralized platforms for collective intelligence and planetary-scale problem-solving, guiding us toward an epistemic revolution at this critical time.",
- "track": "Coordination",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Research",
+ "id": "how-to-do-something-to-some-state-in-some-contract",
+ "sourceId": "HECBJV",
+ "title": "How to do something to some state in some contract",
+ "description": "Smart contracts are changing. \r\n\r\nSo far, they needed every transaction to be public in order for nodes to agree. Zero-Knowledge came in to change things a bit: you can actually make your transaction client-side and just broadcast a proof.\r\n\r\nIn this workshop, we will use Noir and write a simple Aztec and/or Ethereum contract that allows for most of the execution and state to remain private.",
+ "track": "Applied Cryptography",
+ "type": "Workshop",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Semantic Governance",
- "Identity",
- "Citizens Assembly"
+ "ZKDSL",
+ "DevOps",
+ "Mobile Proving"
],
"tags": [
- "Consensus",
- "Quadratic Voting",
- "Collective Intelligence",
- "citizens",
- "assembly",
- "Collective Intelligence",
- "Consensus",
- "Quadratic Voting"
+ "DevEx",
+ "Privacy",
+ "Decentralization",
+ "Cryptography",
+ "Mobile",
+ "proving",
+ "Cryptography",
+ "Decentralization",
+ "DevEx",
+ "Privacy"
],
"language": "en",
"speakers": [
- "nick-almond"
+ "jose-pedro-sousa-or-zpedro"
],
"eventId": "devcon-7",
- "slot_start": 1731643800000,
- "slot_end": 1731645600000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1sq5KPHZmGsWxfhQtVwIBL6Wm8XGy-QAB5wFPQck9lO4"
+ "slot_start": 1731638700000,
+ "slot_end": 1731644100000,
+ "slot_roomId": "classroom-d",
+ "resources_presentation": "https://docs.google.com/presentation/d/1V-PhhZNdNFgdu0_mbGXOQJjINihO5JLwJV7DDAJh4nc"
},
"vector": [
0,
@@ -404108,7 +403270,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -404491,11 +403652,9 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -404855,7 +404014,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -404864,6 +404022,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -404873,18 +404032,19 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -404951,6 +404111,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -404962,7 +404123,9 @@
0,
0,
0,
+ 2,
0,
+ 2,
0,
0,
0,
@@ -405059,7 +404222,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -405222,8 +404384,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -405410,14 +404570,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
2,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -405433,39 +404592,33 @@
},
{
"session": {
- "id": "how-to-destroy-a-network-offboarding-the-mainstream",
- "sourceId": "XNCFRL",
- "title": "How To Destroy A Network: Offboarding The Mainstream",
- "description": "Crafting Ethereum into a setting (both technically and reputationally) where The Institutions feel comfortable participating in it at scale has been the life work of hundreds of people over the last nine years. And yet, for our success, many feel that the victory has come at a cost too heavy to bear: our losing focus as to why we built the global computer in the first place. If you feel the same way, join me for a brief exploration of what would need to happen for us to cut the cord.",
- "track": "Cypherpunk & Privacy",
+ "id": "how-to-hallucinate-a-server",
+ "sourceId": "QNFTYG",
+ "title": "How To Hallucinate A Server",
+ "description": "A Hallucinated Server is a virtual server whose execution is cryptographically simulated by users, using \"multiplayer\" privacy technologies like multi-party computation or fully homomorphic encryption. Today, thanks to recent advancements in MPC and FHE, we have the technology to build the first fully Turing-complete hallucinated servers. We discuss the underlying technologies, and how we've used them to build several proof-of-concept applications.",
+ "track": "Applied Cryptography",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Values"
+ "MPFHE",
+ "Hallucinated Server"
],
"tags": [
- "Network State",
- "Privacy",
- "Anonymity",
- "Digital Sovereignty",
- "value",
- "Anonymity",
- "Digital Sovereignty",
- "Network State",
- "Privacy"
+ "Homomorphic Encryption",
+ "MPC"
],
"language": "en",
"speakers": [
- "laurence-day"
+ "gubsheep"
],
"eventId": "devcon-7",
- "slot_start": 1731484200000,
- "slot_end": 1731486000000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1mVbPl6HPZouYDklCGe84dKqjwtSkE7VTKOYNdWU6URc"
+ "slot_start": 1731552300000,
+ "slot_end": 1731554100000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1wOtuuxn-pV_UdYT74yaBeuoxLyXyxkk_KW0-5GBqLJk"
},
"vector": [
0,
@@ -405473,12 +404626,12 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -405650,6 +404803,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -405862,7 +405016,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -406246,7 +405399,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -406267,10 +405419,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -406309,6 +405459,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -406336,7 +405488,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -406594,7 +405745,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -406785,12 +405935,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -406803,42 +405953,48 @@
},
{
"session": {
- "id": "how-to-do-something-to-some-state-in-some-contract",
- "sourceId": "HECBJV",
- "title": "How to do something to some state in some contract",
- "description": "Smart contracts are changing. \r\n\r\nSo far, they needed every transaction to be public in order for nodes to agree. Zero-Knowledge came in to change things a bit: you can actually make your transaction client-side and just broadcast a proof.\r\n\r\nIn this workshop, we will use Noir and write a simple Aztec and/or Ethereum contract that allows for most of the execution and state to remain private.",
- "track": "Applied Cryptography",
- "type": "Workshop",
+ "id": "how-to-onboard-22-million-users-overnight-using-non-conventional-cryptography",
+ "sourceId": "SDPVVF",
+ "title": "How to onboard 22 million users overnight using non-conventional cryptography",
+ "description": "Since 2004, the Mexican tax administration started to issue digital identity certificates that linked government IDs to sovereign private keys. These has facilitated the electronic invoicing system that is designed around a public key infrastructure maintained by the central bank.\r\n\r\nThis infrastructure has provided with private keys to over 22 million people. We're onboarding all of those using Account Abstraction in a friendly-manner.",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "ZKDSL",
- "DevOps",
- "Mobile Proving"
- ],
"tags": [
- "DevEx",
- "Privacy",
- "Decentralization",
+ "Identity",
"Cryptography",
- "Mobile",
- "proving",
+ "Account Abstraction",
+ "pki",
+ "Account Abstraction",
"Cryptography",
- "Decentralization",
- "DevEx",
- "Privacy"
+ "Identity"
],
- "language": "en",
- "speakers": [
- "jose-pedro-sousa-or-zpedro"
+ "keywords": [
+ "ERC-4337",
+ "RSA",
+ "PKI"
],
+ "duration": 495,
+ "language": "en",
+ "sources_swarmHash": "27f0ff51b8cf2bd6235c4f7c336e2d44d2515212562c231633e54fcb571a19f5",
+ "sources_youtubeId": "DKJYpdXsOwQ",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731638700000,
- "slot_end": 1731644100000,
- "slot_roomId": "classroom-d",
- "resources_presentation": "https://docs.google.com/presentation/d/1V-PhhZNdNFgdu0_mbGXOQJjINihO5JLwJV7DDAJh4nc"
+ "slot_start": 1731479400000,
+ "slot_end": 1731480000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/131bdLWEGmE-yZLMUwmeE98y-D2mP5uniqwKdaak6J1c",
+ "resources_slides": null,
+ "speakers": [
+ "ernesto-garcia"
+ ]
},
"vector": [
0,
@@ -406847,10 +406003,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -406955,6 +406107,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -407236,30 +406389,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -407606,7 +406735,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -407616,14 +406744,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -407633,6 +406759,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -407668,7 +406795,9 @@
0,
0,
0,
+ 2,
0,
+ 2,
0,
0,
0,
@@ -407695,7 +406824,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -407707,9 +406835,7 @@
0,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
@@ -407994,6 +407120,30 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -408154,7 +407304,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -408167,6 +407316,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -408176,41 +407329,42 @@
},
{
"session": {
- "id": "how-to-hallucinate-a-server",
- "sourceId": "QNFTYG",
- "title": "How To Hallucinate A Server",
- "description": "A Hallucinated Server is a virtual server whose execution is cryptographically simulated by users, using \"multiplayer\" privacy technologies like multi-party computation or fully homomorphic encryption. Today, thanks to recent advancements in MPC and FHE, we have the technology to build the first fully Turing-complete hallucinated servers. We discuss the underlying technologies, and how we've used them to build several proof-of-concept applications.",
- "track": "Applied Cryptography",
- "type": "Talk",
+ "id": "how-to-raise-the-gas-limit-use-ultra-high-resolution-data",
+ "sourceId": "UASADN",
+ "title": "How to Raise the Gas Limit: Use Ultra High Resolution Data",
+ "description": "Recent advances in EVM data processing enable a more rigorous approach for understanding and enacting Ethereum’s scaling roadmap. In the past, discussions around whether to raise Ethereum’s gas limit have been held back by imprecise terminology and a lack of detailed quantitative evidence. The debate is often “vibes-based”. Leveraging ultra high resolution datasets enables a more scientific understanding of the gas limit, including issues like state growth, hardware bottlenecks, and gas pricing.",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "MPFHE",
- "Hallucinated Server"
+ "Gas limit",
+ "State growth",
+ "History growth",
+ "Bandwidth"
],
"tags": [
- "Homomorphic Encryption",
- "MPC"
+ "Layer 1",
+ "Gas",
+ "Scalability",
+ "bandwidth",
+ "Gas",
+ "Layer 1",
+ "Scalability"
],
"language": "en",
"speakers": [
- "gubsheep"
+ "storm-slivkoff"
],
"eventId": "devcon-7",
- "slot_start": 1731552300000,
- "slot_end": 1731554100000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1wOtuuxn-pV_UdYT74yaBeuoxLyXyxkk_KW0-5GBqLJk"
+ "slot_start": 1731569400000,
+ "slot_end": 1731570000000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1EM_PJu06t3IYa4m6iVVoVQ2AnVXrc2iJ4B-8uWHtzAE"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -408388,7 +407542,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -408607,6 +407760,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -408974,6 +408129,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -409046,8 +408202,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -409100,6 +408254,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -409186,6 +408341,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -409333,6 +408489,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -409522,8 +408679,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -409540,59 +408697,48 @@
},
{
"session": {
- "id": "how-to-onboard-22-million-users-overnight-using-non-conventional-cryptography",
- "sourceId": "SDPVVF",
- "title": "How to onboard 22 million users overnight using non-conventional cryptography",
- "description": "Since 2004, the Mexican tax administration started to issue digital identity certificates that linked government IDs to sovereign private keys. These has facilitated the electronic invoicing system that is designed around a public key infrastructure maintained by the central bank.\r\n\r\nThis infrastructure has provided with private keys to over 22 million people. We're onboarding all of those using Account Abstraction in a friendly-manner.",
- "track": "Real World Ethereum",
+ "id": "how-to-steal-dollar11m-from-lending-market-in-15-minutes",
+ "sourceId": "TJ833L",
+ "title": "How to steal $1.1M from lending market in 15 minutes",
+ "description": "In may 2024 I found multiple bugs in lending market which allowed to steal $1.1 mln. The exploit itself was very complicated and required multiple steps, including exploitation of liquidation process of unhealthy loan which worked very similar to flash loan. \r\nI'll tell the story of how I decided to check this project source code to finding an issue, contacting with owners of platform and fixing it. I'll also share the best tips how to avoid and prevent such issues in other projects.",
+ "track": "Security",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Identity",
- "Cryptography",
- "Account Abstraction",
- "pki",
- "Account Abstraction",
- "Cryptography",
- "Identity"
- ],
"keywords": [
- "ERC-4337",
- "RSA",
- "PKI"
+ "defi",
+ "lending protocols",
+ "exploit"
+ ],
+ "tags": [
+ "Security",
+ "Auditing",
+ "Bug",
+ "exploits",
+ "Auditing",
+ "Bug",
+ "Security"
],
- "duration": 495,
"language": "en",
- "sources_swarmHash": "27f0ff51b8cf2bd6235c4f7c336e2d44d2515212562c231633e54fcb571a19f5",
- "sources_youtubeId": "DKJYpdXsOwQ",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
+ "speakers": [
+ "bartosz-barwikowski"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731479400000,
- "slot_end": 1731480000000,
+ "slot_start": 1731657600000,
+ "slot_end": 1731658200000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/131bdLWEGmE-yZLMUwmeE98y-D2mP5uniqwKdaak6J1c",
- "resources_slides": null,
- "speakers": [
- "ernesto-garcia"
- ]
+ "resources_presentation": "https://docs.google.com/presentation/d/1_JwwqcHhRqpyNIOuusmiEAr-roI7bAxIOH-9iiMKSaM"
},
"vector": [
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -409695,7 +408841,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -409983,6 +409128,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -410335,6 +409481,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -410349,7 +409496,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -410385,9 +409531,7 @@
0,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
@@ -410489,6 +409633,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -410610,6 +409755,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -410896,17 +410042,16 @@
0,
0,
0,
- 0,
2,
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -410919,49 +410064,55 @@
},
{
"session": {
- "id": "how-to-raise-the-gas-limit-use-ultra-high-resolution-data",
- "sourceId": "UASADN",
- "title": "How to Raise the Gas Limit: Use Ultra High Resolution Data",
- "description": "Recent advances in EVM data processing enable a more rigorous approach for understanding and enacting Ethereum’s scaling roadmap. In the past, discussions around whether to raise Ethereum’s gas limit have been held back by imprecise terminology and a lack of detailed quantitative evidence. The debate is often “vibes-based”. Leveraging ultra high resolution datasets enables a more scientific understanding of the gas limit, including issues like state growth, hardware bottlenecks, and gas pricing.",
- "track": "Core Protocol",
- "type": "Lightning Talk",
+ "id": "how-web3-and-rwas-unlock-exponential-wealth-via-a-computable-economy",
+ "sourceId": "GFAA97",
+ "title": "How Web3 and RWAs Unlock Exponential Wealth via a Computable Economy.",
+ "description": "Keynote based on Justin Banon And Prof. Jason Potts academic paper: How Web3 enables the transition to a new computable economy and exponential growth in economic complexity, wealth, and prosperity by extending the reliability and programmability of on-chain transactions to the entire economy via RWA tokenization. Web3 is not just a new information technology, it is a new institutional technology on the scale of language, writing and code.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Business",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Gas limit",
- "State growth",
- "History growth",
- "Bandwidth"
- ],
"tags": [
- "Layer 1",
- "Gas",
- "Scalability",
- "bandwidth",
- "Gas",
- "Layer 1",
- "Scalability"
+ "RWA",
+ "Economics",
+ "web3",
+ "Economics",
+ "RWA"
],
- "language": "en",
- "speakers": [
- "storm-slivkoff"
+ "keywords": [
+ "Web3"
],
+ "duration": 1461,
+ "language": "en",
+ "sources_swarmHash": "7973ee90af2d2e28084a7ccfb9e884a2054adff1ea6d872dfcad14f5d7a07916",
+ "sources_youtubeId": "yuEFLaSk7us",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731569400000,
- "slot_end": 1731570000000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1EM_PJu06t3IYa4m6iVVoVQ2AnVXrc2iJ4B-8uWHtzAE"
+ "slot_start": 1731405600000,
+ "slot_end": 1731407400000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1rY0yIyNGkdtc2aIioukR3vUzIU0ERrllvWthuyIH1UU",
+ "resources_slides": null,
+ "speakers": [
+ "justin-banon",
+ "jason-potts"
+ ]
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -411352,6 +410503,11 @@
0,
0,
6,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -411722,7 +410878,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -411734,6 +410889,12 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -411935,7 +411096,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -412047,44 +411207,31 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
0,
0,
0,
@@ -412273,9 +411420,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -412290,48 +411437,55 @@
},
{
"session": {
- "id": "how-to-steal-dollar11m-from-lending-market-in-15-minutes",
- "sourceId": "TJ833L",
- "title": "How to steal $1.1M from lending market in 15 minutes",
- "description": "In may 2024 I found multiple bugs in lending market which allowed to steal $1.1 mln. The exploit itself was very complicated and required multiple steps, including exploitation of liquidation process of unhealthy loan which worked very similar to flash loan. \r\nI'll tell the story of how I decided to check this project source code to finding an issue, contacting with owners of platform and fixing it. I'll also share the best tips how to avoid and prevent such issues in other projects.",
- "track": "Security",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "human-stories-of-real-world-ethereum-next-billion-fellows-ef",
+ "sourceId": "7SXGVX",
+ "title": "Human stories of real world Ethereum - Next Billion Fellows (EF)",
+ "description": "Next Billion Fellows work on projects that give a glimpse of what Ethereum means to everyday people. Through their lens, we can see what human coordination might look like someday. Come discuss the realworld, tangible impact of Ethereum on Fellows’ communities and explore the challenges they face along the way.",
+ "track": "Real World Ethereum",
+ "type": "Workshop",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "defi",
- "lending protocols",
- "exploit"
+ "real",
+ "world",
+ "usecases"
],
"tags": [
- "Security",
- "Auditing",
- "Bug",
- "exploits",
- "Auditing",
- "Bug",
- "Security"
+ "Free Speech",
+ "Not financial",
+ "Public good",
+ "Quadratic Voting",
+ "Use Cases"
],
"language": "en",
"speakers": [
- "bartosz-barwikowski"
+ "team-next-billion-ef",
+ "david-uzochukwu",
+ "eddie-kago",
+ "guo-liu",
+ "mercedes-rodriguez-simon",
+ "valeriia-panina",
+ "karam-alhamad",
+ "tomislav-mamic",
+ "rebecca-mqamelo",
+ "lefteris-arapakis"
],
"eventId": "devcon-7",
- "slot_start": 1731657600000,
- "slot_end": 1731658200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1_JwwqcHhRqpyNIOuusmiEAr-roI7bAxIOH-9iiMKSaM"
+ "slot_start": 1731486600000,
+ "slot_end": 1731497400000,
+ "slot_roomId": "breakout-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1cnh924lOiBxB_1BdOH0enegLlg7UzzZ8tJU5R7Qt-wI"
},
"vector": [
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -412404,6 +411558,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -412690,6 +411845,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -412723,6 +411879,13 @@
0,
0,
6,
+ 6,
+ 6,
+ 6,
+ 6,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -413077,18 +412240,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -413104,6 +412255,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -413155,6 +412307,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -413184,6 +412337,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -413229,7 +412383,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -413284,6 +412437,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -413310,6 +412464,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -413352,7 +412507,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -413454,7 +412608,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -413642,12 +412795,10 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -413660,44 +412811,52 @@
},
{
"session": {
- "id": "how-web3-and-rwas-unlock-exponential-wealth-via-a-computable-economy",
- "sourceId": "GFAA97",
- "title": "How Web3 and RWAs Unlock Exponential Wealth via a Computable Economy.",
- "description": "Keynote based on Justin Banon And Prof. Jason Potts academic paper: How Web3 enables the transition to a new computable economy and exponential growth in economic complexity, wealth, and prosperity by extending the reliability and programmability of on-chain transactions to the entire economy via RWA tokenization. Web3 is not just a new information technology, it is a new institutional technology on the scale of language, writing and code.",
- "track": "Real World Ethereum",
- "type": "Talk",
+ "id": "hunt-the-bug-save-the-chain-uncovering-bugs-in-eip-implementations",
+ "sourceId": "UQ8MWW",
+ "title": "Hunt the Bug, Save the Chain: Uncovering Bugs in EIP Implementations",
+ "description": "In this workshop you can find a bug in an EIP implementation on a test network!\r\n\r\nThe Ethereum Foundation Testing Team oversees cross-client execution specification testing, which is critical to avoid consensus issues at the smart-contract execution level.\r\n\r\nYou'll implement tests for a new EIP from scratch using the ethereum/execution-spec-tests framework and execute them on a local test network with a faulty client. Anyone attending has the chance to find the issue and break the network!",
+ "track": "Core Protocol",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Business",
- "featured": false,
+ "audience": "Engineering",
+ "featured": true,
"doNotRecord": false,
"tags": [
- "RWA",
- "Economics",
- "web3",
- "Economics",
- "RWA"
+ "Core Protocol",
+ "Security",
+ "Testing",
+ "python",
+ "pytest",
+ "specs",
+ "Core Protocol",
+ "Security",
+ "Testing"
],
"keywords": [
- "Web3"
+ "Python",
+ "Pytest",
+ "Specs"
],
- "duration": 1461,
+ "duration": 6666,
"language": "en",
- "sources_swarmHash": "7973ee90af2d2e28084a7ccfb9e884a2054adff1ea6d872dfcad14f5d7a07916",
- "sources_youtubeId": "yuEFLaSk7us",
+ "sources_swarmHash": "d6bd3d078ed4fb9ae1b8c781897264b4738782f469f0d370dea340349c2b9587",
+ "sources_youtubeId": "K0pQ7bRuJOk",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
"transcript_vtt": "No VTT link provided",
"transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731405600000,
- "slot_end": 1731407400000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1rY0yIyNGkdtc2aIioukR3vUzIU0ERrllvWthuyIH1UU",
+ "slot_start": 1731472200000,
+ "slot_end": 1731479400000,
+ "slot_roomId": "classroom-d",
+ "resources_presentation": "https://docs.google.com/presentation/d/117F-s4Jnf3r7cRIQqAwsYqwIGULHx4JTcdJjW64wZag",
"resources_slides": null,
"speakers": [
- "justin-banon",
- "jason-potts"
+ "mario-vega",
+ "danceratopz",
+ "dimitry-kh",
+ "spencer-taylor-brown"
]
},
"vector": [
@@ -413705,8 +412864,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -414099,12 +413256,6 @@
0,
0,
0,
- 6,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -414116,6 +413267,10 @@
0,
0,
0,
+ 6,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -414454,6 +413609,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -414472,6 +413628,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -414488,7 +413645,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -414607,7 +413763,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -414694,6 +413849,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -414832,8 +413988,8 @@
0,
0,
2,
- 0,
- 0,
+ 2,
+ 2,
0,
0,
0,
@@ -415018,10 +414174,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -415036,46 +414192,37 @@
},
{
"session": {
- "id": "human-stories-of-real-world-ethereum-next-billion-fellows-ef",
- "sourceId": "7SXGVX",
- "title": "Human stories of real world Ethereum - Next Billion Fellows (EF)",
- "description": "Next Billion Fellows work on projects that give a glimpse of what Ethereum means to everyday people. Through their lens, we can see what human coordination might look like someday. Come discuss the realworld, tangible impact of Ethereum on Fellows’ communities and explore the challenges they face along the way.",
- "track": "Real World Ethereum",
- "type": "Workshop",
+ "id": "i-read-every-single-1990s-cypherpunk-email-heres-what-you-should-know",
+ "sourceId": "V8FHZL",
+ "title": "I read every single 1990s Cypherpunk email. Here's what you should know.",
+ "description": "What would Hal Finney, Tim May, David Chaum, and other cypherpunks think about the current state of Ethereum, cryptography, privacy, and trusted hardware? I read every single 1990s cypherpunk email (thousands) to learn more the original movement. I gathered the most interesting and relevant cypherpunk emails, and put them together to make this best-of-the-best cypherpunk presentation.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Talk",
"expertise": "Beginner",
"audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "real",
- "world",
- "usecases"
+ "Cypherpunk"
],
"tags": [
+ "Permissionless",
"Free Speech",
- "Not financial",
- "Public good",
- "Quadratic Voting",
- "Use Cases"
+ "Censorship Resistance",
+ "cypherpunk",
+ "Censorship Resistance",
+ "Free Speech",
+ "Permissionless"
],
"language": "en",
"speakers": [
- "team-next-billion-ef",
- "david-uzochukwu",
- "eddie-kago",
- "guo-liu",
- "mercedes-rodriguez-simon",
- "valeriia-panina",
- "karam-alhamad",
- "tomislav-mamic",
- "rebecca-mqamelo",
- "lefteris-arapakis"
+ "porter-adams"
],
"eventId": "devcon-7",
- "slot_start": 1731486600000,
- "slot_end": 1731497400000,
- "slot_roomId": "breakout-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1cnh924lOiBxB_1BdOH0enegLlg7UzzZ8tJU5R7Qt-wI"
+ "slot_start": 1731484800000,
+ "slot_end": 1731486600000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1GfxZnDdh1oYJ0Cmi0EqvJ6n5WY4Rvok97rq_GW9HmJA"
},
"vector": [
0,
@@ -415083,7 +414230,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -415157,7 +414303,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -415445,7 +414590,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -415478,14 +414622,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
- 6,
- 6,
- 6,
- 6,
0,
0,
0,
@@ -415500,6 +414636,14 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -415909,7 +415053,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -415939,7 +415082,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -415980,6 +415122,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -416039,7 +415182,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -416067,7 +415209,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -416097,6 +415238,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -416212,6 +415355,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -416413,52 +415557,42 @@
},
{
"session": {
- "id": "hunt-the-bug-save-the-chain-uncovering-bugs-in-eip-implementations",
- "sourceId": "UQ8MWW",
- "title": "Hunt the Bug, Save the Chain: Uncovering Bugs in EIP Implementations",
- "description": "In this workshop you can find a bug in an EIP implementation on a test network!\r\n\r\nThe Ethereum Foundation Testing Team oversees cross-client execution specification testing, which is critical to avoid consensus issues at the smart-contract execution level.\r\n\r\nYou'll implement tests for a new EIP from scratch using the ethereum/execution-spec-tests framework and execute them on a local test network with a faulty client. Anyone attending has the chance to find the issue and break the network!",
- "track": "Core Protocol",
- "type": "Workshop",
- "expertise": "Intermediate",
- "audience": "Engineering",
- "featured": true,
+ "id": "impossibility-within-dynamically-available-protocols",
+ "sourceId": "SUNDNH",
+ "title": "Impossibility within Dynamically Available Protocols",
+ "description": "This talk will be about dynamically available protocols and their properties. LMD-GHOST which is the fork choice rule for Ethereum consensus currently can face ex-ante and re-org attacks. GoldFish and other protocols aim to fix this but they themselves then face problems with asynchrony resilience and subcommittees. \r\nI also want to present possible solutions to these issues and establish some impossibility results that might be useful in consensus research for path towards single slot finality.",
+ "track": "[CLS] EPF Day",
+ "type": "Lightning Talk",
+ "expertise": "Expert",
+ "audience": "Academic",
+ "featured": false,
"doNotRecord": false,
"tags": [
- "Core Protocol",
- "Security",
- "Testing",
- "python",
- "pytest",
- "specs",
- "Core Protocol",
- "Security",
- "Testing"
+ "Consensus Mechanisms",
+ "Finality",
+ "Single-slot Finality"
],
"keywords": [
- "Python",
- "Pytest",
- "Specs"
+ "Dynamic",
+ "Availability"
],
- "duration": 6666,
+ "duration": 847,
"language": "en",
- "sources_swarmHash": "d6bd3d078ed4fb9ae1b8c781897264b4738782f469f0d370dea340349c2b9587",
- "sources_youtubeId": "K0pQ7bRuJOk",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "bMdgQbD5v3E",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
"transcript_vtt": "No VTT link provided",
"transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731472200000,
- "slot_end": 1731479400000,
- "slot_roomId": "classroom-d",
- "resources_presentation": "https://docs.google.com/presentation/d/117F-s4Jnf3r7cRIQqAwsYqwIGULHx4JTcdJjW64wZag",
+ "slot_start": 1731488400000,
+ "slot_end": 1731489300000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1_2sjOdakXbWTFCsQUBSCgpvHSd9_OwHcKRN41aiBnJc",
"resources_slides": null,
"speakers": [
- "mario-vega",
- "danceratopz",
- "dimitry-kh",
- "spencer-taylor-brown"
+ "yash-saraswat"
]
},
"vector": [
@@ -416466,7 +415600,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -416478,6 +415611,11 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -416870,9 +416008,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
6,
0,
0,
@@ -417214,7 +416349,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -417233,7 +416367,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -417406,6 +416539,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -417455,7 +416590,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -417593,7 +416727,6 @@
0,
0,
0,
- 2,
2,
2,
0,
@@ -417775,9 +416908,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
2,
0,
@@ -417789,6 +416919,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -417797,46 +416928,54 @@
},
{
"session": {
- "id": "i-read-every-single-1990s-cypherpunk-email-heres-what-you-should-know",
- "sourceId": "V8FHZL",
- "title": "I read every single 1990s Cypherpunk email. Here's what you should know.",
- "description": "What would Hal Finney, Tim May, David Chaum, and other cypherpunks think about the current state of Ethereum, cryptography, privacy, and trusted hardware? I read every single 1990s cypherpunk email (thousands) to learn more the original movement. I gathered the most interesting and relevant cypherpunk emails, and put them together to make this best-of-the-best cypherpunk presentation.",
- "track": "Cypherpunk & Privacy",
- "type": "Talk",
+ "id": "improving-the-user-experience-by-user-research",
+ "sourceId": "ZVUFEY",
+ "title": "Improving the User Experience by User Research.",
+ "description": "This workshop will help you understand your users and their needs, motivations and problems because this is a critical stage in product development.\r\nThis will help reduce development risks and costs through improved user experience, decision validity, increased user loyalty, etc.\r\nWe will practice in-depth interviews at the workshop, analyze its results and create a Customer Journey Map.",
+ "track": "Usability",
+ "type": "Workshop",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Cypherpunk"
- ],
"tags": [
- "Permissionless",
- "Free Speech",
- "Censorship Resistance",
- "cypherpunk",
- "Censorship Resistance",
- "Free Speech",
- "Permissionless"
+ "User Experience",
+ "Interface",
+ "Accessibility",
+ "User Research",
+ "adoption",
+ "blockchain",
+ "mass",
+ "Accessibility",
+ "Interface",
+ "User Experience",
+ "User Research"
],
- "language": "en",
- "speakers": [
- "porter-adams"
+ "keywords": [
+ "Customer Journey Map",
+ "In-depth interviews",
+ "Blockchain Mass Adoption."
],
+ "duration": 4254,
+ "language": "en",
+ "sources_swarmHash": "e32e0f241560e407a1450d712a6db039fb681b3956e5c8e6798b4616c6a901b3",
+ "sources_youtubeId": "F3yRHm4ybmQ",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731484800000,
- "slot_end": 1731486600000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1GfxZnDdh1oYJ0Cmi0EqvJ6n5WY4Rvok97rq_GW9HmJA"
+ "slot_start": 1731389400000,
+ "slot_end": 1731394800000,
+ "slot_roomId": "classroom-c",
+ "resources_presentation": "https://docs.google.com/presentation/d/1FKJnGwx0Fa6M46QKoFqfn0W7-iZIbFqvnLkxjd-Pct0",
+ "resources_slides": null,
+ "speakers": [
+ "andrii-bondar"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
0,
0,
0,
@@ -417845,6 +416984,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -418242,7 +417382,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -418250,6 +417389,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -418601,6 +417741,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -418609,7 +417750,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -418645,6 +417785,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -418671,6 +417812,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -418725,12 +417867,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -418741,6 +417883,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -418780,6 +417924,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -418847,7 +417992,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -418964,7 +418108,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -419151,7 +418294,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -419160,48 +418302,45 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "impossibility-within-dynamically-available-protocols",
- "sourceId": "SUNDNH",
- "title": "Impossibility within Dynamically Available Protocols",
- "description": "This talk will be about dynamically available protocols and their properties. LMD-GHOST which is the fork choice rule for Ethereum consensus currently can face ex-ante and re-org attacks. GoldFish and other protocols aim to fix this but they themselves then face problems with asynchrony resilience and subcommittees. \r\nI also want to present possible solutions to these issues and establish some impossibility results that might be useful in consensus research for path towards single slot finality.",
- "track": "[CLS] EPF Day",
+ "id": "incentivizing-defensive-technologies-for-ethereum",
+ "sourceId": "HTNYKL",
+ "title": "Incentivizing Defensive Technologies for Ethereum",
+ "description": "Creating incentives and funding mechanisms for defensive technologies is a novel problem.\r\n\r\nHere's a preliminary outline:\r\n* History of defensive technology development. \r\n* Incentives and funding mechanisms for defensive technologies.\r\n* Public good funding mechanisms.\r\n* Impact certificates.\r\n* Technology trees.\r\n* Evaluating impact.\r\n* Prediction markets.\r\n* Defensive technologies for Ethereum.\r\n* Incentivizing defensive technologies for Ethereum.",
+ "track": "Real World Ethereum",
"type": "Lightning Talk",
- "expertise": "Expert",
- "audience": "Academic",
+ "expertise": "Beginner",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Consensus Mechanisms",
- "Finality",
- "Single-slot Finality"
- ],
"keywords": [
- "Dynamic",
- "Availability"
+ "d/acc",
+ "defensive technologies"
+ ],
+ "tags": [
+ "Regenative Ethereum",
+ "Ethereum for Good",
+ "e/acc",
+ "technology",
+ "defense",
+ "e/acc",
+ "Ethereum for Good",
+ "Regenative Ethereum"
],
- "duration": 847,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "bMdgQbD5v3E",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731488400000,
- "slot_end": 1731489300000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1_2sjOdakXbWTFCsQUBSCgpvHSd9_OwHcKRN41aiBnJc",
- "resources_slides": null,
"speakers": [
- "yash-saraswat"
- ]
+ "han-tuzun"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731658200000,
+ "slot_end": 1731658800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1fuSrN9JQHv91E6bFCwDtFCGMP2T4Sg6pk3Mhh_y-ZYg"
},
"vector": [
0,
@@ -419210,6 +418349,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -419219,7 +418360,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -420078,6 +419218,17 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -420097,6 +419248,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -420150,28 +419309,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -420341,6 +419478,7 @@
0,
2,
2,
+ 2,
0,
0,
0,
@@ -420517,8 +419655,7 @@
0,
0,
0,
- 0,
- 0,
+ 2,
0,
2,
0,
@@ -420530,7 +419667,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -420539,52 +419675,25 @@
},
{
"session": {
- "id": "improving-the-user-experience-by-user-research",
- "sourceId": "ZVUFEY",
- "title": "Improving the User Experience by User Research.",
- "description": "This workshop will help you understand your users and their needs, motivations and problems because this is a critical stage in product development.\r\nThis will help reduce development risks and costs through improved user experience, decision validity, increased user loyalty, etc.\r\nWe will practice in-depth interviews at the workshop, analyze its results and create a Customer Journey Map.",
- "track": "Usability",
- "type": "Workshop",
- "expertise": "Beginner",
- "audience": "Product",
+ "id": "inch",
+ "sourceId": "AWQHPU",
+ "title": "INCH",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "User Experience",
- "Interface",
- "Accessibility",
- "User Research",
- "adoption",
- "blockchain",
- "mass",
- "Accessibility",
- "Interface",
- "User Experience",
- "User Research"
- ],
- "keywords": [
- "Customer Journey Map",
- "In-depth interviews",
- "Blockchain Mass Adoption."
- ],
- "duration": 4254,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "e32e0f241560e407a1450d712a6db039fb681b3956e5c8e6798b4616c6a901b3",
- "sources_youtubeId": "F3yRHm4ybmQ",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731389400000,
- "slot_end": 1731394800000,
- "slot_roomId": "classroom-c",
- "resources_presentation": "https://docs.google.com/presentation/d/1FKJnGwx0Fa6M46QKoFqfn0W7-iZIbFqvnLkxjd-Pct0",
- "resources_slides": null,
- "speakers": [
- "andrii-bondar"
- ]
+ "slot_start": 1731580200000,
+ "slot_end": 1731583800000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1XIExS1_AoQ1qy7x-JA9-WtnrbRg6bJqnZ5hnpK-w-Sw"
},
"vector": [
0,
@@ -420595,6 +419704,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -421001,7 +420111,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -421355,7 +420464,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -421399,7 +420507,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -421426,7 +420533,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -421481,7 +420587,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -421497,8 +420602,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -421538,7 +420641,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -421902,10 +421004,10 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
0,
0,
2,
@@ -421917,54 +421019,64 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
0
]
},
{
"session": {
- "id": "incentivizing-defensive-technologies-for-ethereum",
- "sourceId": "HTNYKL",
- "title": "Incentivizing Defensive Technologies for Ethereum",
- "description": "Creating incentives and funding mechanisms for defensive technologies is a novel problem.\r\n\r\nHere's a preliminary outline:\r\n* History of defensive technology development. \r\n* Incentives and funding mechanisms for defensive technologies.\r\n* Public good funding mechanisms.\r\n* Impact certificates.\r\n* Technology trees.\r\n* Evaluating impact.\r\n* Prediction markets.\r\n* Defensive technologies for Ethereum.\r\n* Incentivizing defensive technologies for Ethereum.",
- "track": "Real World Ethereum",
+ "id": "inclusion-list-inevitable-tradeoffs",
+ "sourceId": "XEE9EG",
+ "title": "Inclusion List Inevitable Tradeoffs",
+ "description": "Inclusion lists have been a popular topic over the years, with various versions emerging, such as EIP-7547 and FOCIL. All these inclusion lists are constrained by a common trade-off: the Ethereum slot time. This talk explores the details of this trade-off and examines whether there is a \"best\" solution given these constraints.",
+ "track": "Cryptoeconomics",
"type": "Lightning Talk",
"expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "d/acc",
- "defensive technologies"
- ],
"tags": [
- "Regenative Ethereum",
- "Ethereum for Good",
- "e/acc",
- "technology",
- "defense",
- "e/acc",
- "Ethereum for Good",
- "Regenative Ethereum"
+ "Decentralization Improvements",
+ "Censorship Resistance",
+ "inclusivity",
+ "lists",
+ "Censorship Resistance",
+ "Decentralization Improvements"
],
- "language": "en",
- "speakers": [
- "han-tuzun"
+ "keywords": [
+ "inclusion",
+ "list"
],
+ "duration": 426,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "Z3au-5R2iiQ",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673473f09dbb7a90e128f649.vtt",
+ "transcript_text": " So this one is more again on inclusion this and it's more on the engineering side that as someone that has been focusing on inclusion this over the last year and I also started looking at fossil more and more and this is where my perspective in terms of engineering challenge with regards to inclusion is. So today, where we are, right? So today we have Ethereum slot and each slot is 12 seconds. And what are the constraints within the slot? So as a proposer, I want to propose a block. And I would hate to have my block gets reorg and that's not nice So I want to propose My block on the strongest head that's possible right and after I propose a block everyone else on the network that's running a node will verify the block and compute what is the head and As a tester their job is to attest to the head of the block So this is where the for choice follows if you use lmdGhost, and then as an aggregator, as optional, you aggregate attestations, and then the proposer essentially follows the votes for the next slot, and then it builds on top of the head. And then because of timing game, you can see there is a phenomenon that today, the attester caught up is at four seconds. So basically everything is pushed towards a four second mark. And that's kind of the equilibrium right now that everything happens within three to four seconds. And then between four to 12 seconds of nothing typically happens unless you are the next law proposer, you are listening to transactions, and you are building blood. So where does inclusion list fit in into this picture? So here I'm speaking in terms of Fossil. So Fossil is a EIP 7805 I believe, but go search it if you don't know what Fossil is. So Fossil is probably the best inclusion list design that I have seen so far that is mostly bully-proof, in my opinion. And then it has the same slot property. And then, so what Fossil does essentially is that it essentially allows secondary runs of proposals that are allowed to send their local block and then such that it can train the next slot proposer, essentially. So where does that leave us in the picture, right? So because of that, we have to essentially add this proposer in the middle of the 12 slots. That means that as a proposer for the inclusion disk, I have to essentially verify the block beforehand, such that I want to essentially propose the block beforehand such that I want to essentially propose the best inclusion disk effort, right? And then as a constraint, the next slot builder or the proposer, I have to essentially pack the inclusion disk into the block. And then if I miss inclusion disk, then I may miss my block. And also as a tester, I want to make sure that the block satisfies the inclusion this. So there are three more constraints as a builder, as a proposer, as a tester, which I cover here. So where are some parameters that we can play in terms of trade-off? So for example, how big is the size of an inclusion disk? If the inclusion disk size is so small that it may not be useful, but the inclusion disk size is too big, then you open up network for DOS concerns. What is the size of the inclusion disk committee? Because we want committee size to be reasonable, but then if the size is too big again you open up network does concern and then how much overlapping are there within the inclusion this and then what is the satisfactory rule right so as a proposal for the next slot as a tester i'm verifying the block like what like basically like how much of the inclusion this the proposal has to satisfy for the block block to be valid. So what are the concerns? So first concern, I think, is the increase of bandwidth and compute for node. Like, depends on how big your inclusion disk size is. And then, again, the second concern is that proposer, like, how much time do I have to build the block? And then, as a tester, how much time do I have to verify the block? So here are some open questions for us to study if we're interested in this inclusion disk space. How compatible it is with the future roadmap, such as peer-dos, such as EPPS? How does inclusion disk work with account abstraction? And then how can we add block transactions into the inclusion disk such that it doesn't open up those concerns? And then how can we better utilize local mempool for inclusion disk? Maybe we can just essentially send the transaction hash instead of sending the full transactions. Finally, will there be other protocol market for inclusion disk? And it's something that we need to study more. So yeah, if you're interested to contribute, hit up julian and hit up me and then yeah definitely i'm definitely very excited about this inclusion this design space thank you thank you so now we have time for a few Q&A. Please raise your hand if you have any questions. OK. No questions? OK, it seems that there's a question here. Yeah, super interesting. I had a question. So I don't know if you can answer this but um in any capacity are you thinking about doing fossil or inclusion lists for l2s like arbitrum or yeah and how is that different from wasn't the eip and what could be on mainnet right so there too today is most of the literature or all of the literature today they have just one sequencer right so the sequencer definitely have a lot of power say today if you want to force your transactions in there like if sequencer ignores you there's nothing you can do but then there's a lot of people say well you can force transaction through layer 1 but that's also not nice because you have to wait like 24 hours right but then like I think like decentralized sequencer kind of self-set if you assume an honest majority so I would say the space in terms of censorship resistance on there too it's it's definitely very different on there one because on there too you can essentially having like 1 million validators you could just have like 10 sequencers and then trust like honest majority and then as long as you assume some of them are honest, and they were, like basically, basically they have to include your transactions. Any other question? Okay, well, thank you very much for your talk. Please give some applause to Terence.",
"eventId": "devcon-7",
- "slot_start": 1731658200000,
- "slot_end": 1731658800000,
+ "slot_start": 1731489600000,
+ "slot_end": 1731490200000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1fuSrN9JQHv91E6bFCwDtFCGMP2T4Sg6pk3Mhh_y-ZYg"
+ "resources_presentation": "https://docs.google.com/presentation/d/18aJAdqUOqTUSwaSiW85kTjIKaVx1BRU7lQDigrzc_wc",
+ "resources_slides": null,
+ "speakers": [
+ "terence"
+ ]
},
"vector": [
0,
0,
+ 6,
0,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -422296,6 +421408,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -422372,7 +421485,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -422713,6 +421825,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -422835,7 +421948,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -422855,6 +421967,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -422865,7 +421978,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -423096,8 +422208,6 @@
0,
2,
2,
- 2,
- 0,
0,
0,
0,
@@ -423292,33 +422402,41 @@
},
{
"session": {
- "id": "inch",
- "sourceId": "AWQHPU",
- "title": "INCH",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
+ "id": "indexing-entire-24-billion-transactions-on-ethereum-in-10-hours",
+ "sourceId": "QEDEUG",
+ "title": "Indexing Entire 2.4 Billion Transactions on Ethereum in 10 Hours",
+ "description": "This talk covers learnings from building a general-purpose indexer which index every single transaction since genesis. There is also technical decisions when we have to deal with 7 billions records of data and how to process all of those data in less than half a day. Additionally, we will discuss the difference between batch data processing and real-time data processing, sharing best practices and strategies for both approaches.",
+ "track": "Developer Experience",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Data",
+ "Processing"
+ ],
+ "tags": [
+ "Architecture",
+ "Scalability",
+ "Event monitoring",
+ "data",
+ "processor",
+ "Architecture",
+ "Event monitoring",
+ "Scalability"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "panjamapong-panj-sermsawatsri"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731580200000,
- "slot_end": 1731583800000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1XIExS1_AoQ1qy7x-JA9-WtnrbRg6bJqnZ5hnpK-w-Sw"
+ "slot_start": 1731492600000,
+ "slot_end": 1731493200000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1e7StVYyUS6PD_m8Qka4g3W8mafU8txCAZgD9XA95sSI"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -423734,6 +422852,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -424129,6 +423248,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -424206,6 +423326,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -424316,6 +423437,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -424374,6 +423496,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -424452,6 +423575,44 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -424586,50 +423747,10 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
2,
0,
0,
+ 0,
2,
0,
0,
@@ -424648,55 +423769,45 @@
},
{
"session": {
- "id": "inclusion-list-inevitable-tradeoffs",
- "sourceId": "XEE9EG",
- "title": "Inclusion List Inevitable Tradeoffs",
- "description": "Inclusion lists have been a popular topic over the years, with various versions emerging, such as EIP-7547 and FOCIL. All these inclusion lists are constrained by a common trade-off: the Ethereum slot time. This talk explores the details of this trade-off and examines whether there is a \"best\" solution given these constraints.",
- "track": "Cryptoeconomics",
- "type": "Lightning Talk",
- "expertise": "Beginner",
+ "id": "indexing-ethereum-when-and-how-to-build-an-indexer",
+ "sourceId": "BGGFDD",
+ "title": "Indexing Ethereum: When and How to Build an Indexer",
+ "description": "Open source Ethereum Indexers are great for quickly getting your project off the ground. However, there are limits to these tools and in some cases building your own Indexer is the right thing to do. This talk will explore why you might want to build your own and outline a technical approach for building simple, reliable Indexers.",
+ "track": "Developer Experience",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Decentralization Improvements",
- "Censorship Resistance",
- "inclusivity",
- "lists",
- "Censorship Resistance",
- "Decentralization Improvements"
- ],
"keywords": [
- "inclusion",
- "list"
+ "database",
+ "indexing",
+ "infrastructure"
+ ],
+ "tags": [
+ "Architecture",
+ "Developer Infrastructure",
+ "Best Practices",
+ "infrastructure",
+ "Architecture",
+ "Best Practices",
+ "Developer Infrastructure"
],
- "duration": 426,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "Z3au-5R2iiQ",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673473f09dbb7a90e128f649.vtt",
- "transcript_text": " So this one is more again on inclusion this and it's more on the engineering side that as someone that has been focusing on inclusion this over the last year and I also started looking at fossil more and more and this is where my perspective in terms of engineering challenge with regards to inclusion is. So today, where we are, right? So today we have Ethereum slot and each slot is 12 seconds. And what are the constraints within the slot? So as a proposer, I want to propose a block. And I would hate to have my block gets reorg and that's not nice So I want to propose My block on the strongest head that's possible right and after I propose a block everyone else on the network that's running a node will verify the block and compute what is the head and As a tester their job is to attest to the head of the block So this is where the for choice follows if you use lmdGhost, and then as an aggregator, as optional, you aggregate attestations, and then the proposer essentially follows the votes for the next slot, and then it builds on top of the head. And then because of timing game, you can see there is a phenomenon that today, the attester caught up is at four seconds. So basically everything is pushed towards a four second mark. And that's kind of the equilibrium right now that everything happens within three to four seconds. And then between four to 12 seconds of nothing typically happens unless you are the next law proposer, you are listening to transactions, and you are building blood. So where does inclusion list fit in into this picture? So here I'm speaking in terms of Fossil. So Fossil is a EIP 7805 I believe, but go search it if you don't know what Fossil is. So Fossil is probably the best inclusion list design that I have seen so far that is mostly bully-proof, in my opinion. And then it has the same slot property. And then, so what Fossil does essentially is that it essentially allows secondary runs of proposals that are allowed to send their local block and then such that it can train the next slot proposer, essentially. So where does that leave us in the picture, right? So because of that, we have to essentially add this proposer in the middle of the 12 slots. That means that as a proposer for the inclusion disk, I have to essentially verify the block beforehand, such that I want to essentially propose the block beforehand such that I want to essentially propose the best inclusion disk effort, right? And then as a constraint, the next slot builder or the proposer, I have to essentially pack the inclusion disk into the block. And then if I miss inclusion disk, then I may miss my block. And also as a tester, I want to make sure that the block satisfies the inclusion this. So there are three more constraints as a builder, as a proposer, as a tester, which I cover here. So where are some parameters that we can play in terms of trade-off? So for example, how big is the size of an inclusion disk? If the inclusion disk size is so small that it may not be useful, but the inclusion disk size is too big, then you open up network for DOS concerns. What is the size of the inclusion disk committee? Because we want committee size to be reasonable, but then if the size is too big again you open up network does concern and then how much overlapping are there within the inclusion this and then what is the satisfactory rule right so as a proposal for the next slot as a tester i'm verifying the block like what like basically like how much of the inclusion this the proposal has to satisfy for the block block to be valid. So what are the concerns? So first concern, I think, is the increase of bandwidth and compute for node. Like, depends on how big your inclusion disk size is. And then, again, the second concern is that proposer, like, how much time do I have to build the block? And then, as a tester, how much time do I have to verify the block? So here are some open questions for us to study if we're interested in this inclusion disk space. How compatible it is with the future roadmap, such as peer-dos, such as EPPS? How does inclusion disk work with account abstraction? And then how can we add block transactions into the inclusion disk such that it doesn't open up those concerns? And then how can we better utilize local mempool for inclusion disk? Maybe we can just essentially send the transaction hash instead of sending the full transactions. Finally, will there be other protocol market for inclusion disk? And it's something that we need to study more. So yeah, if you're interested to contribute, hit up julian and hit up me and then yeah definitely i'm definitely very excited about this inclusion this design space thank you thank you so now we have time for a few Q&A. Please raise your hand if you have any questions. OK. No questions? OK, it seems that there's a question here. Yeah, super interesting. I had a question. So I don't know if you can answer this but um in any capacity are you thinking about doing fossil or inclusion lists for l2s like arbitrum or yeah and how is that different from wasn't the eip and what could be on mainnet right so there too today is most of the literature or all of the literature today they have just one sequencer right so the sequencer definitely have a lot of power say today if you want to force your transactions in there like if sequencer ignores you there's nothing you can do but then there's a lot of people say well you can force transaction through layer 1 but that's also not nice because you have to wait like 24 hours right but then like I think like decentralized sequencer kind of self-set if you assume an honest majority so I would say the space in terms of censorship resistance on there too it's it's definitely very different on there one because on there too you can essentially having like 1 million validators you could just have like 10 sequencers and then trust like honest majority and then as long as you assume some of them are honest, and they were, like basically, basically they have to include your transactions. Any other question? Okay, well, thank you very much for your talk. Please give some applause to Terence.",
- "eventId": "devcon-7",
- "slot_start": 1731489600000,
- "slot_end": 1731490200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/18aJAdqUOqTUSwaSiW85kTjIKaVx1BRU7lQDigrzc_wc",
- "resources_slides": null,
"speakers": [
- "terence"
- ]
+ "ryan-smith"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731481200000,
+ "slot_end": 1731483000000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1UA3bcjbOHIUGe57PEX-2bhr64qsal8zYSkn0UedXY0E"
},
"vector": [
- 0,
- 0,
- 6,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -425029,7 +424140,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -425110,6 +424220,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -425448,7 +424559,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -425474,6 +424584,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -425496,6 +424607,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -425503,6 +424615,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -425590,7 +424703,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -425629,6 +424741,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -425830,8 +424943,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -426003,9 +425114,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
2,
0,
@@ -426025,46 +425136,40 @@
},
{
"session": {
- "id": "indexing-entire-24-billion-transactions-on-ethereum-in-10-hours",
- "sourceId": "QEDEUG",
- "title": "Indexing Entire 2.4 Billion Transactions on Ethereum in 10 Hours",
- "description": "This talk covers learnings from building a general-purpose indexer which index every single transaction since genesis. There is also technical decisions when we have to deal with 7 billions records of data and how to process all of those data in less than half a day. Additionally, we will discuss the difference between batch data processing and real-time data processing, sharing best practices and strategies for both approaches.",
- "track": "Developer Experience",
- "type": "Lightning Talk",
+ "id": "indistinguishability-obfuscation-io",
+ "sourceId": "KDUKFD",
+ "title": "Indistinguishability Obfuscation (iO)",
+ "description": "There has been a lot of recent progress and interest in iO (Indistinguishability Obfuscation). This session will cover topics from the basics to theory and attempts at practical implementations—plus ways of breaking these attempts.",
+ "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Data",
- "Processing"
+ "Programmable Cryptography",
+ "iO"
],
"tags": [
- "Architecture",
- "Scalability",
- "Event monitoring",
- "data",
- "processor",
- "Architecture",
- "Event monitoring",
- "Scalability"
+ "Cryptography"
],
"language": "en",
"speakers": [
- "panjamapong-panj-sermsawatsri"
+ "barry",
+ "tianyao-gu",
+ "b-l",
+ "janmajaya-mall"
],
"eventId": "devcon-7",
- "slot_start": 1731492600000,
- "slot_end": 1731493200000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1e7StVYyUS6PD_m8Qka4g3W8mafU8txCAZgD9XA95sSI"
+ "slot_start": 1731654900000,
+ "slot_end": 1731660300000,
+ "slot_roomId": "breakout-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ezCRXGstLPjkBZnbw-GuffthHA6ChZ3jbGvDnrUxbyk"
},
"vector": [
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -426076,6 +425181,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -426248,6 +425354,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -426438,6 +425545,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -426477,6 +425585,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -426820,6 +425929,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -426874,8 +425984,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -426952,7 +426060,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -427064,7 +426171,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -427123,7 +426229,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -427202,7 +426307,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -427377,7 +426481,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -427388,6 +426491,7 @@
0,
0,
0,
+ 2,
0,
0,
0
@@ -427395,83 +426499,46 @@
},
{
"session": {
- "id": "indexing-ethereum-when-and-how-to-build-an-indexer",
- "sourceId": "BGGFDD",
- "title": "Indexing Ethereum: When and How to Build an Indexer",
- "description": "Open source Ethereum Indexers are great for quickly getting your project off the ground. However, there are limits to these tools and in some cases building your own Indexer is the right thing to do. This talk will explore why you might want to build your own and outline a technical approach for building simple, reliable Indexers.",
- "track": "Developer Experience",
- "type": "Talk",
+ "id": "insights-from-block-propagation-in-the-ethereum-p2p-network",
+ "sourceId": "T8GXPY",
+ "title": "Insights from block propagation in the Ethereum P2P network",
+ "description": "Libp2p’s Gossipsub protocol is one of the most critical pieces of the Ethereum protocol stack, disseminating blocks between nodes on time and ensuring that misbehaving nodes are rejected from the network. ProbeLab has studied the performance of Gossipsub in Ethereum’s P2P network, building tooling to monitor block propagations and spot abnormalities.\r\nWe revealed ample space for optimisation in the protocol, which will help define the next steps in Ethereum's roadmap. Come and hear our findings!",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "database",
- "indexing",
- "infrastructure"
+ "Block Propagation",
+ "Networking Protocols"
],
"tags": [
+ "Core Protocol",
"Architecture",
- "Developer Infrastructure",
- "Best Practices",
- "infrastructure",
+ "Scalability",
+ "network",
+ "protocol",
"Architecture",
- "Best Practices",
- "Developer Infrastructure"
+ "Core Protocol",
+ "Scalability"
],
"language": "en",
"speakers": [
- "ryan-smith"
+ "mikel-cortes-cortze"
],
"eventId": "devcon-7",
- "slot_start": 1731481200000,
- "slot_end": 1731483000000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1UA3bcjbOHIUGe57PEX-2bhr64qsal8zYSkn0UedXY0E"
+ "slot_start": 1731570600000,
+ "slot_end": 1731571200000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Do39xW55yzxbDah8ClU174jW2BCWeaJUCWQ-N15sadE"
},
"vector": [
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -427847,7 +426914,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -427887,6 +426953,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -428213,7 +427280,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -428244,7 +427310,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -428280,6 +427345,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -428305,6 +427371,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -428356,6 +427423,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -428370,7 +427438,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -428606,6 +427673,37 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -428743,7 +427841,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -428752,6 +427849,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -428765,35 +427866,39 @@
},
{
"session": {
- "id": "indistinguishability-obfuscation-io",
- "sourceId": "KDUKFD",
- "title": "Indistinguishability Obfuscation (iO)",
- "description": "There has been a lot of recent progress and interest in iO (Indistinguishability Obfuscation). This session will cover topics from the basics to theory and attempts at practical implementations—plus ways of breaking these attempts.",
- "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC",
- "type": "Workshop",
+ "id": "interoperability-between-l2s-latest-developments-framework-and-challenges",
+ "sourceId": "3ZH9ST",
+ "title": "Interoperability between L2s: Latest developments, Framework and Challenges",
+ "description": "The number of L2s is growing rapidly and it’s crucial to create strong interoperability solutions to reduce liquidity fragmentation and friction for users. We provide a framework for analyzing interoperability solutions that defines 6 levels of interoperability. For each level, we deep dive the consequences on UX, DevEx, scalability, fee structures, and MEV potential. We also provide an ecosystem map categorizing the level of interoperability offered by existing projects.",
+ "track": "Layer 2",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Programmable Cryptography",
- "iO"
+ "Composability",
+ "Interoperability"
],
"tags": [
- "Cryptography"
+ "Fragmentation",
+ "Cross-L2",
+ "Developer Infrastructure",
+ "interoperability",
+ "Cross-L2",
+ "Developer Infrastructure",
+ "Fragmentation"
],
"language": "en",
"speakers": [
- "barry",
- "tianyao-gu",
- "b-l",
- "janmajaya-mall"
+ "marshall-vyletel-jr",
+ "wei-dai"
],
"eventId": "devcon-7",
- "slot_start": 1731654900000,
- "slot_end": 1731660300000,
- "slot_roomId": "breakout-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1ezCRXGstLPjkBZnbw-GuffthHA6ChZ3jbGvDnrUxbyk"
+ "slot_start": 1731579600000,
+ "slot_end": 1731580200000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1DgmkfIFJfD0vf-bVsGTFZt1Nv09KHD5RE7ct8x0puek"
},
"vector": [
0,
@@ -428803,6 +427908,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -428810,11 +427916,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -428984,7 +428085,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -429175,7 +428275,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -429214,8 +428313,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -429224,6 +428321,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -429561,7 +428660,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -429595,6 +428693,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -429605,6 +428704,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -429750,6 +428850,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -429940,6 +429041,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -430113,6 +429215,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -430123,7 +429226,6 @@
0,
0,
0,
- 2,
0,
0,
0
@@ -430131,45 +429233,41 @@
},
{
"session": {
- "id": "insights-from-block-propagation-in-the-ethereum-p2p-network",
- "sourceId": "T8GXPY",
- "title": "Insights from block propagation in the Ethereum P2P network",
- "description": "Libp2p’s Gossipsub protocol is one of the most critical pieces of the Ethereum protocol stack, disseminating blocks between nodes on time and ensuring that misbehaving nodes are rejected from the network. ProbeLab has studied the performance of Gossipsub in Ethereum’s P2P network, building tooling to monitor block propagations and spot abnormalities.\r\nWe revealed ample space for optimisation in the protocol, which will help define the next steps in Ethereum's roadmap. Come and hear our findings!",
- "track": "Core Protocol",
- "type": "Lightning Talk",
+ "id": "interpreting-solidity",
+ "sourceId": "GQAEZX",
+ "title": "Interpreting Solidity",
+ "description": "In this talk, we present an alternative way of executing Solidity: interpreting it.\r\nFoundry popularized writing more in Solidity, including tests and scripts. However, the compilation model is limiting for some use cases, such as interactive environments or general purpose scripting. We first describe how interpreting can solve many of these limitations, then, we explain how to build such an interpreter, finally, we present a Solidity REPL that we built using this approach: https://eclair.so",
+ "track": "Developer Experience",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Developper",
"featured": false,
- "doNotRecord": false,
+ "doNotRecord": true,
"keywords": [
- "Block Propagation",
- "Networking Protocols"
+ "NA"
],
"tags": [
- "Core Protocol",
- "Architecture",
- "Scalability",
- "network",
- "protocol",
- "Architecture",
- "Core Protocol",
- "Scalability"
+ "Developer Infrastructure",
+ "Tooling",
+ "Languages",
+ "Developer Infrastructure",
+ "Languages",
+ "Tooling"
],
"language": "en",
"speakers": [
- "mikel-cortes-cortze"
+ "daniel-perez"
],
"eventId": "devcon-7",
- "slot_start": 1731570600000,
- "slot_end": 1731571200000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1Do39xW55yzxbDah8ClU174jW2BCWeaJUCWQ-N15sadE"
+ "slot_start": 1731578400000,
+ "slot_end": 1731580200000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1YKUtPFBeb26s1YkKpnXAOT5YJuWFJaIAKmQLoipb0oM"
},
"vector": [
0,
0,
0,
- 0,
6,
0,
0,
@@ -430586,10 +429684,10 @@
0,
0,
0,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -430970,6 +430068,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -430980,7 +430079,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -431006,7 +430104,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -431014,6 +430111,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -431058,7 +430156,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -431309,7 +430406,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -431484,7 +430580,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -431492,6 +430587,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -431501,39 +430597,39 @@
},
{
"session": {
- "id": "interoperability-between-l2s-latest-developments-framework-and-challenges",
- "sourceId": "3ZH9ST",
- "title": "Interoperability between L2s: Latest developments, Framework and Challenges",
- "description": "The number of L2s is growing rapidly and it’s crucial to create strong interoperability solutions to reduce liquidity fragmentation and friction for users. We provide a framework for analyzing interoperability solutions that defines 6 levels of interoperability. For each level, we deep dive the consequences on UX, DevEx, scalability, fee structures, and MEV potential. We also provide an ecosystem map categorizing the level of interoperability offered by existing projects.",
- "track": "Layer 2",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "introducing-provable-object-data",
+ "sourceId": "YP9HRR",
+ "title": "Introducing Provable Object Data",
+ "description": "Built on learnings from experimental projects like Zupass, Provable Object Data (POD) is a new format with open-source libraries for any app to issue verifiable data, and make ZK proofs of claims about that data. PODs allow arbitrary key/value data to be signed and distributed. Flexible proofs about PODs can be created using a highly-configurable family of General Purpose Circuits (GPCs), without app-specific circuits or trusted setup. This talk will focus on POD and GPC motivation and design.",
+ "track": "Applied Cryptography",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Composability",
- "Interoperability"
+ "Zupass",
+ "developers",
+ "POD"
],
"tags": [
- "Fragmentation",
- "Cross-L2",
- "Developer Infrastructure",
- "interoperability",
- "Cross-L2",
- "Developer Infrastructure",
- "Fragmentation"
+ "Libraries",
+ "Zero-Knowledge",
+ "Use cases of cryptography",
+ "pod",
+ "Libraries",
+ "Use cases of cryptography",
+ "Zero-Knowledge"
],
"language": "en",
"speakers": [
- "marshall-vyletel-jr",
- "wei-dai"
+ "andrew-twyman"
],
"eventId": "devcon-7",
- "slot_start": 1731579600000,
- "slot_end": 1731580200000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1DgmkfIFJfD0vf-bVsGTFZt1Nv09KHD5RE7ct8x0puek"
+ "slot_start": 1731569400000,
+ "slot_end": 1731571200000,
+ "slot_roomId": "classroom-b",
+ "resources_presentation": "https://docs.google.com/presentation/d/1M8ozawZM8Xme8xRHKoop-7XlGGAjINE02ztaxWPyaXo"
},
"vector": [
0,
@@ -431543,10 +430639,10 @@
0,
0,
0,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -431560,6 +430656,7 @@
0,
0,
0,
+ 4,
0,
0,
0,
@@ -431957,8 +431054,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -432297,6 +431392,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -432312,6 +431409,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -432331,7 +431429,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -432342,7 +431439,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -432488,7 +431584,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -432678,9 +431773,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -432864,49 +431959,48 @@
0,
0,
0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "interpreting-solidity",
- "sourceId": "GQAEZX",
- "title": "Interpreting Solidity",
- "description": "In this talk, we present an alternative way of executing Solidity: interpreting it.\r\nFoundry popularized writing more in Solidity, including tests and scripts. However, the compilation model is limiting for some use cases, such as interactive environments or general purpose scripting. We first describe how interpreting can solve many of these limitations, then, we explain how to build such an interpreter, finally, we present a Solidity REPL that we built using this approach: https://eclair.so",
- "track": "Developer Experience",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Developper",
+ "id": "introduction-to-hash-based-proof-systems",
+ "sourceId": "EUAERD",
+ "title": "Introduction to hash-based proof systems",
+ "description": "Over the last decade, ZK has been gaining attention due to its applications in verifiable private computation and the scalability of blockchains. The development of general-purpose zkvms powered with STARK/hash-based proof systems have made writing provable applications simpler, abstracting developers from the details of ZK. In this talk, we will explain the basics of hash-based proof systems, different arithmetization schemes and how to prove computations without needing a trusted setup.",
+ "track": "Applied Cryptography",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Engineering",
"featured": false,
- "doNotRecord": true,
+ "doNotRecord": false,
"keywords": [
- "NA"
+ "Binius",
+ "Reed-Solomon"
],
"tags": [
- "Developer Infrastructure",
- "Tooling",
- "Languages",
- "Developer Infrastructure",
- "Languages",
- "Tooling"
+ "Scalability",
+ "ZKP",
+ "STARK",
+ "reed-solomon",
+ "Scalability",
+ "STARK",
+ "ZKP"
],
"language": "en",
"speakers": [
- "daniel-perez"
+ "diego-kingston"
],
"eventId": "devcon-7",
- "slot_start": 1731578400000,
- "slot_end": 1731580200000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1YKUtPFBeb26s1YkKpnXAOT5YJuWFJaIAKmQLoipb0oM"
+ "slot_start": 1731392400000,
+ "slot_end": 1731393000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/13SZq6cgLNu-xaLH6s8Xx4zOAbocLGeK_vQMElFVIUtU"
},
"vector": [
0,
0,
0,
- 6,
0,
0,
0,
@@ -432914,6 +432008,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -433676,7 +432771,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -433709,9 +432803,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -433731,6 +432822,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -433752,7 +432844,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -433796,6 +432887,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -433866,6 +432958,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -434047,6 +433140,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -434218,6 +433312,7 @@
0,
2,
0,
+ 2,
0,
0,
0,
@@ -434228,9 +433323,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0
@@ -434238,39 +433330,42 @@
},
{
"session": {
- "id": "introducing-provable-object-data",
- "sourceId": "YP9HRR",
- "title": "Introducing Provable Object Data",
- "description": "Built on learnings from experimental projects like Zupass, Provable Object Data (POD) is a new format with open-source libraries for any app to issue verifiable data, and make ZK proofs of claims about that data. PODs allow arbitrary key/value data to be signed and distributed. Flexible proofs about PODs can be created using a highly-configurable family of General Purpose Circuits (GPCs), without app-specific circuits or trusted setup. This talk will focus on POD and GPC motivation and design.",
+ "id": "introduction-to-multilateral-trade-credit-set-off-in-mpc",
+ "sourceId": "VYD38F",
+ "title": "Introduction to Multilateral Trade Credit Set-off in MPC",
+ "description": "Multilateral Trade Credit Set-off is a process for collecting outstanding invoices from a network of firms and detecting cycles. A cycle is a circular pattern of due payments that connects businesses. Removing a cycle yields liquidity savings for the firms involved. This process is done by a central agency that collects the invoices and performs the netting. Instead, we leverage MPC to perform the set-ff while preserving the privacy of sensitive financial data of the firms",
"track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Developer",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Zupass",
- "developers",
- "POD"
- ],
"tags": [
- "Libraries",
- "Zero-Knowledge",
- "Use cases of cryptography",
- "pod",
- "Libraries",
- "Use cases of cryptography",
- "Zero-Knowledge"
+ "finance"
],
- "language": "en",
- "speakers": [
- "andrew-twyman"
+ "keywords": [
+ "MPC",
+ "cryptography",
+ "finance"
],
+ "duration": 680,
+ "language": "en",
+ "sources_swarmHash": "7a26e690c86585c39a8f2060e0df78edb94d20dc82bf22ba67b3c85cdc3d2bcb",
+ "sources_youtubeId": "OCEEe8azbR8",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731569400000,
- "slot_end": 1731571200000,
- "slot_roomId": "classroom-b",
- "resources_presentation": "https://docs.google.com/presentation/d/1M8ozawZM8Xme8xRHKoop-7XlGGAjINE02ztaxWPyaXo"
+ "slot_start": 1731391200000,
+ "slot_end": 1731391800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1uaHx0jU0Bz-S7lJarLkDXQgyJwYi9XQaoCd5IniQ4ls",
+ "resources_slides": null,
+ "speakers": [
+ "enrico-bottazzi"
+ ]
},
"vector": [
0,
@@ -434297,7 +433392,6 @@
0,
0,
0,
- 4,
0,
0,
0,
@@ -434698,6 +433792,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -435036,8 +434132,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -435053,7 +434147,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -435585,6 +434678,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -435592,8 +434686,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -435608,38 +434700,27 @@
},
{
"session": {
- "id": "introduction-to-hash-based-proof-systems",
- "sourceId": "EUAERD",
- "title": "Introduction to hash-based proof systems",
- "description": "Over the last decade, ZK has been gaining attention due to its applications in verifiable private computation and the scalability of blockchains. The development of general-purpose zkvms powered with STARK/hash-based proof systems have made writing provable applications simpler, abstracting developers from the details of ZK. In this talk, we will explain the basics of hash-based proof systems, different arithmetization schemes and how to prove computations without needing a trusted setup.",
+ "id": "io",
+ "sourceId": "9BQWGB",
+ "title": "iO",
+ "description": "It will be worth it ;)",
"track": "Applied Cryptography",
- "type": "Lightning Talk",
- "expertise": "Beginner",
+ "type": "Talk",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Binius",
- "Reed-Solomon"
- ],
- "tags": [
- "Scalability",
- "ZKP",
- "STARK",
- "reed-solomon",
- "Scalability",
- "STARK",
- "ZKP"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
"speakers": [
- "diego-kingston"
+ "barry-whitehat"
],
"eventId": "devcon-7",
- "slot_start": 1731392400000,
- "slot_end": 1731393000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/13SZq6cgLNu-xaLH6s8Xx4zOAbocLGeK_vQMElFVIUtU"
+ "slot_start": 1731555000000,
+ "slot_end": 1731556800000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1RcEikB5_ALOwZaJQaAvBqDR_O7aF9ycww9YUXYxXCFA"
},
"vector": [
0,
@@ -436066,8 +435147,8 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -436469,7 +435550,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -436534,7 +435614,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -436605,7 +435684,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -436788,7 +435866,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -436959,6 +436036,7 @@
0,
2,
0,
+ 0,
2,
0,
0,
@@ -436977,52 +436055,41 @@
},
{
"session": {
- "id": "introduction-to-multilateral-trade-credit-set-off-in-mpc",
- "sourceId": "VYD38F",
- "title": "Introduction to Multilateral Trade Credit Set-off in MPC",
- "description": "Multilateral Trade Credit Set-off is a process for collecting outstanding invoices from a network of firms and detecting cycles. A cycle is a circular pattern of due payments that connects businesses. Removing a cycle yields liquidity savings for the firms involved. This process is done by a central agency that collects the invoices and performs the netting. Instead, we leverage MPC to perform the set-ff while preserving the privacy of sensitive financial data of the firms",
- "track": "Applied Cryptography",
+ "id": "is-multi-block-mev-a-thing-insights-from-2-years-of-mev-boost-data",
+ "sourceId": "E3JADX",
+ "title": "Is multi-block MEV a thing? Insights from 2 years of MEV Boost Data",
+ "description": "Multi-block MEV describes MEV that arises from one party controlling several consecutive slots. Currently, it is discussed as a potential blocker for several prominent mechanism designs. We analyzed two years of MEV boost data covering more than 5 million slots to investigate historical patterns of it. Amongst other findings we see less multi-slot sequences occur than randomly feasible however that payments for longer sequences are higher than average.",
+ "track": "Cryptoeconomics",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "tags": [
- "finance"
- ],
"keywords": [
- "MPC",
- "cryptography",
- "finance"
+ "Multi-block MEV",
+ "Data Analysis"
+ ],
+ "tags": [
+ "Economics",
+ "Tokenomics",
+ "MEV",
+ "data",
+ "analysis",
+ "Economics",
+ "MEV",
+ "Tokenomics"
],
- "duration": 680,
"language": "en",
- "sources_swarmHash": "7a26e690c86585c39a8f2060e0df78edb94d20dc82bf22ba67b3c85cdc3d2bcb",
- "sources_youtubeId": "OCEEe8azbR8",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731391200000,
- "slot_end": 1731391800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1uaHx0jU0Bz-S7lJarLkDXQgyJwYi9XQaoCd5IniQ4ls",
- "resources_slides": null,
"speakers": [
- "enrico-bottazzi"
- ]
+ "pascal-stichler"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731639300000,
+ "slot_end": 1731639900000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1spOihF0kLB_BzD62uWufsHORVgg_JGXZoISZsJris6M"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
6,
@@ -437065,6 +436132,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -437440,7 +436508,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -437774,6 +436841,9 @@
0,
0,
0,
+ 6,
+ 0,
+ 6,
0,
0,
0,
@@ -437804,6 +436874,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -437812,6 +436883,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -438077,6 +437149,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -438162,7 +437235,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -438332,8 +437404,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -438350,12 +437422,12 @@
},
{
"session": {
- "id": "io",
- "sourceId": "9BQWGB",
- "title": "iO",
- "description": "It will be worth it ;)",
- "track": "Applied Cryptography",
- "type": "Talk",
+ "id": "jackson-the-dev",
+ "sourceId": "GGHN3U",
+ "title": "Jackson the Dev",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
"expertise": "",
"audience": "Engineering",
"featured": false,
@@ -438363,14 +437435,12 @@
"keywords": [],
"tags": [],
"language": "en",
- "speakers": [
- "barry-whitehat"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731555000000,
- "slot_end": 1731556800000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1RcEikB5_ALOwZaJQaAvBqDR_O7aF9ycww9YUXYxXCFA"
+ "slot_start": 1731664800000,
+ "slot_end": 1731668400000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1TAcraJVlaaRRLhKud8QT_bgLYkfYy-QRJtI2GiS2nd4"
},
"vector": [
0,
@@ -438382,7 +437452,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -438799,48 +437868,46 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -439708,45 +438775,47 @@
},
{
"session": {
- "id": "is-multi-block-mev-a-thing-insights-from-2-years-of-mev-boost-data",
- "sourceId": "E3JADX",
- "title": "Is multi-block MEV a thing? Insights from 2 years of MEV Boost Data",
- "description": "Multi-block MEV describes MEV that arises from one party controlling several consecutive slots. Currently, it is discussed as a potential blocker for several prominent mechanism designs. We analyzed two years of MEV boost data covering more than 5 million slots to investigate historical patterns of it. Amongst other findings we see less multi-slot sequences occur than randomly feasible however that payments for longer sequences are higher than average.",
- "track": "Cryptoeconomics",
+ "id": "json-rpc-enhancement-in-geth",
+ "sourceId": "7KZLFF",
+ "title": "JSON-RPC Enhancement in Geth",
+ "description": "Introducing trace_* namespace and eth_getTransactionBySenderAndNonce into ethereum execution clients(geth,reth) to enhance the transaction and trace querying capabilities.",
+ "track": "[CLS] EPF Day",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Multi-block MEV",
- "Data Analysis"
- ],
"tags": [
- "Economics",
- "Tokenomics",
- "MEV",
- "data",
- "analysis",
- "Economics",
- "MEV",
- "Tokenomics"
+ "Architecture",
+ "Frameworks",
+ "User Experience"
],
- "language": "en",
- "speakers": [
- "pascal-stichler"
+ "keywords": [
+ "execution client",
+ "json-rpc"
],
+ "duration": 801,
+ "language": "en",
+ "sources_swarmHash": "4e61ae38126f26ad651edd1931f371700863c255c80b6960001052dbc4aa16af",
+ "sources_youtubeId": "2kO-LVS3tO4",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734298f9dbb7a90e1af087a.vtt",
+ "transcript_text": " Hi everyone, this is Jess Fieser and I come... Thank you. We can state DB and to replace the transitions. This is really slow, and it costs a lot of CPU. So we want to introduce a real-time tracing system, which will offer more efficient and Promoting insights into the EVM execution and it will also support indexing the left execution data such as traces, the state of differ, and the other things So let's see how can we go to how to index source left data. Currently we support indexing traces, which is grouped by a block. And so this is a block number and minus two traces. And us indexing is based on the nonce. So this is when we want to index as a transition senders address plus its nonce to our transition hash. So in my presentation, I'm using KVDB, your status stores, newly created block traces and analysis. This is just a genetic query database, and I use the ETLDB in GALS. For the KIN schema, for the traces, it is just a block number plus block hash and there's a trace tab. And for the NUNs, it is used as a KIN schema is the tracing sender address plus nonce And the failure is just the IOP encoded data So the implementation is very simple For the trace tapers, currently we support the code traces and other traces such as parity traces and the suppressed traces. Here is the workflow of indexing. For each block, we will index each transition based on the TSAT starter hook. And in this hook, we will see if we enable non-traces. If so, we first store the non-traces in the KVDB. And if not, we just continue. And for each transition end, we get the transition result in our local cache. And when the block is ended, we will store the block traces into the KVDB. And in the meantime, we will notify our RSS background for this to notify him we have just indexed a new block. And for this, we will for this newly created traces into rsdb for the efficiency. And so this is just for the indexing and let's see how can we retrieve those data. For the traces, we can retrieve it by the block number and the block hash. And for the transit hashes, for the transitions, We can retrieve it by the block number or block hash. For the transitions, we can feature the block first by the transition hash, and then retrieve it by the block number and feature the transition hash data by its index. For the nonce, it's really simple. We can just retrieve it by the send address and the first nonce is really simple we can just achieve it by the senders address and the nonce and here is just a small follow of block traces which if index yeah it's very simple just read the block number first and check the block data in is the wizard in the kvdb or in the forest number first and check the block data in the KVDB or in the ForestDB and then return back to the column. So, how can I use this feature? As currently, this feature is not merged into the mainnet, into the master branch. So if you are interested, you can follow this PR and see how to use it. The left side is the configuration of the tool. In the feature, you just need to add something like this in the left side. And on the right side, I will introduce every configuration. So first one, path, is just a dictionary which is used to store source data. And the second one, enable nonce-translator, is index the left trace, whether to enable the nonce-trace or not. And the third one, mask-keep-blocks, is just a block limit. So after such blocks, we will print all the data just to save disk size. And for the config, it's a map. It's a map to configure each tracer. And for each detail, you can refer And the first each details we can, you can refer to the built-in, guesses the built-in traces for more detail. Okay. Currently we support source RPCs. It's like as a paratest trace RPC. And the last one is the RPC, just this is just a proposal and it is not enabled for other clients, I think Besides all the parity co-traces, we can also retrieve other gases' native traces I think it is really useful when you want to get history data or history police data for one transaction on one block. We can just like this just RBC, in this example we need to retrieve the police data tracing for block one. So next we can just talk about performance. Yeah, before I talk about performance, in my mind, performance is just a space and time trade-offs. In this implementation, we just use a low-cost disk to store the data instead of high usage of the CPU. So for the advantage of the feature is just you no need to reapply the traces based on this data and the time compensation is very small, it's just all one. And the retrieving is real time, you can index the data and then retrieve it back. And the disadvantage is you need another disk space to store this data, and it may have a little impact on the chain block syncing. Here I just write some benchmarks to compare the results of the Chase R RPC and the Debug RPC. It's a script to retrieve the data from the guest-wise Chess RPC. And this is our results of the Chess RPC results. The upper one is traditional Debug Chess block, and the lower one is traditional debug trace block, and the The later one is trace block. It is about 100 times faster Than the traditional one. Yeah. So it's all thank you. Thank you very much. Your question? Hey, thanks for this. I really appreciate it. I think as a developer, it's sometimes confusing because there's no standardization on the debug or trace namespaces, right? The other RPC methods are in the execution API, so they tend to be standardized across clients. When you move to debug tracing, it becomes a bit trickier. Other than performance, because some clients are going to implement debug, some implement trace namespace, some do both. Other than performance, why would you recommend trace over debug? Is there other reasons you would recommend that option for tracing? It is more customized. You can just index data by your need yeah and the cost is a traditional debug trace which is also support only support such as the parity trace, code trace and the flat code trace and if you wanted to index other things you might need to write a JS, yeah. And the performance is really very, is some part is not very good. So, in this situation, we just introduced this living Chasers framework. And the best on set, you can just write your own Chasers. Right, thank you. I have another question unless someone else, maybe. Probably means that this will be integrated into or when it's going to be added together? Actually, I'm not sure. Maybe this feature will be much into the master branch and insert for or maybe one. No need to have four. Yeah, just add your connection. Maybe can you touch real quick on the, you were talking about some potential issues on the syncing side. You had a con, your second bullet point on the slide where you had frozen cons. Do you remember? There was like two cons you mentioned. One was like additional storage space for trace was one of the disadvantages. And then the second one was you said potential syncing issues. Yeah. Can you touch on that or go a bit more and just explain what you meant by that? Or like at least I guess what you observed when you were benchmarking? I think. I will attend it and maybe in other works. Thank you. Cool. Thanks. So most of the speed improvement looks like it comes from caching and indexing the data. Did you look at indexing the built-in native debug trace? You mean the debug traces? Yeah, the built-in native debug trace? You mean the debug trace? Yeah, the pre-stating the call tracer. So you're basically saying half of the argument is it's faster, but most of that, I suspect, comes from the fact that you're indexing all the data. Did you look at index in the debug trace calls as well? I'm sorry, I have a full answer. So most of the performance increase comes from? Yeah. . Oh, really? Not from the index? Not from index in the data? Yeah, yeah, yeah. Actually, the performance is really depends on the history data. Yeah, you need to feature all the history data, need to replace a transition, so the performance is really, yeah. Because the disk feature is really slow, yeah. I guess, like, piggybacking on that question, like, the improvements that you shipped with Trace, the training namespace, could you not backport them to debug as well, or is that not possible? Yeah, because in the libchaser, the data is just generated and stored when the transaction is used once. And when you use the debug chaser, the data is just replied after the time when you request it. So in this intention, we just start once and the features at any time. That's right, but you're talking specifically about the live tracing here, the real-time tracing, or you're also speaking about when you're, because when you had that graph that was showing 100 milliseconds for trace block, right? And then you had debug trace block at the top. That wasn't for live tracing, right? And then you had debug trace block at the top. That wasn't for live tracing, right? That was just historical calls where you can trace any block, correct? No, no, no. Actually, for trace tracing, you need to index the state force. Yeah, just after the guess is started. Right. Yeah. We got to cut it up here.",
"eventId": "devcon-7",
- "slot_start": 1731639300000,
- "slot_end": 1731639900000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1spOihF0kLB_BzD62uWufsHORVgg_JGXZoISZsJris6M"
+ "slot_start": 1731469500000,
+ "slot_end": 1731470400000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1seSZfQPsg8riFizMYXy6BWgpFjxQVJYELPyjZazrxIc",
+ "resources_slides": null,
+ "speakers": [
+ "jsvisa"
+ ]
},
"vector": [
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -439760,6 +438829,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -439785,7 +438855,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -440171,6 +439240,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -440497,9 +439567,7 @@
0,
0,
0,
- 6,
0,
- 6,
0,
0,
0,
@@ -440511,6 +439579,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -440530,7 +439599,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -440539,7 +439607,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -440558,6 +439625,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -440600,6 +439668,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -440806,7 +439875,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -441060,7 +440128,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -441073,36 +440140,44 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "jackson-the-dev",
- "sourceId": "GGHN3U",
- "title": "Jackson the Dev",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
- "audience": "Engineering",
- "featured": false,
+ "id": "keynote-glass-houses-and-tornados",
+ "sourceId": "K9A8EG",
+ "title": "Keynote: Glass Houses and Tornados",
+ "description": "The Tornado Cash sanctions and criminal prosecutions have challenged longstanding assumptions within crypto about the limits of money transmission licensing, money laundering statutes, and sanctions laws. They've also revealed a longstanding assumption from some in policy and law enforcement circles: that blockchains have always been and must remain transparent. Neither assumption has served us well and the time has come for legal certainty. This talk is about how we get there.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Lobby",
+ "featured": true,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Legal",
+ "Government",
+ "Regulation"
+ ],
+ "tags": [
+ "Governance",
+ "Mixers",
+ "Open Source Software",
+ "Privacy"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "peter-van-valkenburgh"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731664800000,
- "slot_end": 1731668400000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1TAcraJVlaaRRLhKud8QT_bgLYkfYy-QRJtI2GiS2nd4"
+ "slot_start": 1731648600000,
+ "slot_end": 1731649800000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Xs3Tvj3iPf9ArWjPRjf3e7zXu_JG8R-eXuI5yEgHV6c"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -441530,6 +440605,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -441947,7 +441023,9 @@
0,
0,
0,
+ 2,
0,
+ 2,
0,
0,
0,
@@ -441965,6 +441043,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -442243,6 +441322,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -442408,16 +441488,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
- 0,
- 0,
- 2,
- 0,
0,
0,
0,
@@ -442429,60 +441505,46 @@
0,
0,
0,
- 0
+ 2
]
},
{
"session": {
- "id": "json-rpc-enhancement-in-geth",
- "sourceId": "7KZLFF",
- "title": "JSON-RPC Enhancement in Geth",
- "description": "Introducing trace_* namespace and eth_getTransactionBySenderAndNonce into ethereum execution clients(geth,reth) to enhance the transaction and trace querying capabilities.",
- "track": "[CLS] EPF Day",
- "type": "Lightning Talk",
+ "id": "keynote-how-to-properly-open-source-software-lessons-learned-from-the-linux-foundation",
+ "sourceId": "MDHXHK",
+ "title": "Keynote: How to Properly Open Source Software: Lessons Learned from the Linux Foundation",
+ "description": "It can be challenging to properly open source software: there are licenses, IP, security reporting, and many other issues that need to be addressed. In this talk, we will discuss the best practices for open source software development learned from almost 25 years of experience at the Linux Foundation. Attendees will learn about how to set up their projects for a variety of potential goals, including things like maximizing security and community building.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
- "featured": false,
+ "audience": "Developer",
+ "featured": true,
"doNotRecord": false,
- "tags": [
- "Architecture",
- "Frameworks",
- "User Experience"
- ],
"keywords": [
- "execution client",
- "json-rpc"
+ "Linux Foundation",
+ "Open Development"
+ ],
+ "tags": [
+ "Open Source Software",
+ "FOSS",
+ "Best Practices",
+ "development",
+ "open",
+ "Best Practices",
+ "FOSS",
+ "Open Source Software"
],
- "duration": 801,
"language": "en",
- "sources_swarmHash": "4e61ae38126f26ad651edd1931f371700863c255c80b6960001052dbc4aa16af",
- "sources_youtubeId": "2kO-LVS3tO4",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734298f9dbb7a90e1af087a.vtt",
- "transcript_text": " Hi everyone, this is Jess Fieser and I come... Thank you. We can state DB and to replace the transitions. This is really slow, and it costs a lot of CPU. So we want to introduce a real-time tracing system, which will offer more efficient and Promoting insights into the EVM execution and it will also support indexing the left execution data such as traces, the state of differ, and the other things So let's see how can we go to how to index source left data. Currently we support indexing traces, which is grouped by a block. And so this is a block number and minus two traces. And us indexing is based on the nonce. So this is when we want to index as a transition senders address plus its nonce to our transition hash. So in my presentation, I'm using KVDB, your status stores, newly created block traces and analysis. This is just a genetic query database, and I use the ETLDB in GALS. For the KIN schema, for the traces, it is just a block number plus block hash and there's a trace tab. And for the NUNs, it is used as a KIN schema is the tracing sender address plus nonce And the failure is just the IOP encoded data So the implementation is very simple For the trace tapers, currently we support the code traces and other traces such as parity traces and the suppressed traces. Here is the workflow of indexing. For each block, we will index each transition based on the TSAT starter hook. And in this hook, we will see if we enable non-traces. If so, we first store the non-traces in the KVDB. And if not, we just continue. And for each transition end, we get the transition result in our local cache. And when the block is ended, we will store the block traces into the KVDB. And in the meantime, we will notify our RSS background for this to notify him we have just indexed a new block. And for this, we will for this newly created traces into rsdb for the efficiency. And so this is just for the indexing and let's see how can we retrieve those data. For the traces, we can retrieve it by the block number and the block hash. And for the transit hashes, for the transitions, We can retrieve it by the block number or block hash. For the transitions, we can feature the block first by the transition hash, and then retrieve it by the block number and feature the transition hash data by its index. For the nonce, it's really simple. We can just retrieve it by the send address and the first nonce is really simple we can just achieve it by the senders address and the nonce and here is just a small follow of block traces which if index yeah it's very simple just read the block number first and check the block data in is the wizard in the kvdb or in the forest number first and check the block data in the KVDB or in the ForestDB and then return back to the column. So, how can I use this feature? As currently, this feature is not merged into the mainnet, into the master branch. So if you are interested, you can follow this PR and see how to use it. The left side is the configuration of the tool. In the feature, you just need to add something like this in the left side. And on the right side, I will introduce every configuration. So first one, path, is just a dictionary which is used to store source data. And the second one, enable nonce-translator, is index the left trace, whether to enable the nonce-trace or not. And the third one, mask-keep-blocks, is just a block limit. So after such blocks, we will print all the data just to save disk size. And for the config, it's a map. It's a map to configure each tracer. And for each detail, you can refer And the first each details we can, you can refer to the built-in, guesses the built-in traces for more detail. Okay. Currently we support source RPCs. It's like as a paratest trace RPC. And the last one is the RPC, just this is just a proposal and it is not enabled for other clients, I think Besides all the parity co-traces, we can also retrieve other gases' native traces I think it is really useful when you want to get history data or history police data for one transaction on one block. We can just like this just RBC, in this example we need to retrieve the police data tracing for block one. So next we can just talk about performance. Yeah, before I talk about performance, in my mind, performance is just a space and time trade-offs. In this implementation, we just use a low-cost disk to store the data instead of high usage of the CPU. So for the advantage of the feature is just you no need to reapply the traces based on this data and the time compensation is very small, it's just all one. And the retrieving is real time, you can index the data and then retrieve it back. And the disadvantage is you need another disk space to store this data, and it may have a little impact on the chain block syncing. Here I just write some benchmarks to compare the results of the Chase R RPC and the Debug RPC. It's a script to retrieve the data from the guest-wise Chess RPC. And this is our results of the Chess RPC results. The upper one is traditional Debug Chess block, and the lower one is traditional debug trace block, and the The later one is trace block. It is about 100 times faster Than the traditional one. Yeah. So it's all thank you. Thank you very much. Your question? Hey, thanks for this. I really appreciate it. I think as a developer, it's sometimes confusing because there's no standardization on the debug or trace namespaces, right? The other RPC methods are in the execution API, so they tend to be standardized across clients. When you move to debug tracing, it becomes a bit trickier. Other than performance, because some clients are going to implement debug, some implement trace namespace, some do both. Other than performance, why would you recommend trace over debug? Is there other reasons you would recommend that option for tracing? It is more customized. You can just index data by your need yeah and the cost is a traditional debug trace which is also support only support such as the parity trace, code trace and the flat code trace and if you wanted to index other things you might need to write a JS, yeah. And the performance is really very, is some part is not very good. So, in this situation, we just introduced this living Chasers framework. And the best on set, you can just write your own Chasers. Right, thank you. I have another question unless someone else, maybe. Probably means that this will be integrated into or when it's going to be added together? Actually, I'm not sure. Maybe this feature will be much into the master branch and insert for or maybe one. No need to have four. Yeah, just add your connection. Maybe can you touch real quick on the, you were talking about some potential issues on the syncing side. You had a con, your second bullet point on the slide where you had frozen cons. Do you remember? There was like two cons you mentioned. One was like additional storage space for trace was one of the disadvantages. And then the second one was you said potential syncing issues. Yeah. Can you touch on that or go a bit more and just explain what you meant by that? Or like at least I guess what you observed when you were benchmarking? I think. I will attend it and maybe in other works. Thank you. Cool. Thanks. So most of the speed improvement looks like it comes from caching and indexing the data. Did you look at indexing the built-in native debug trace? You mean the debug traces? Yeah, the built-in native debug trace? You mean the debug trace? Yeah, the pre-stating the call tracer. So you're basically saying half of the argument is it's faster, but most of that, I suspect, comes from the fact that you're indexing all the data. Did you look at index in the debug trace calls as well? I'm sorry, I have a full answer. So most of the performance increase comes from? Yeah. . Oh, really? Not from the index? Not from index in the data? Yeah, yeah, yeah. Actually, the performance is really depends on the history data. Yeah, you need to feature all the history data, need to replace a transition, so the performance is really, yeah. Because the disk feature is really slow, yeah. I guess, like, piggybacking on that question, like, the improvements that you shipped with Trace, the training namespace, could you not backport them to debug as well, or is that not possible? Yeah, because in the libchaser, the data is just generated and stored when the transaction is used once. And when you use the debug chaser, the data is just replied after the time when you request it. So in this intention, we just start once and the features at any time. That's right, but you're talking specifically about the live tracing here, the real-time tracing, or you're also speaking about when you're, because when you had that graph that was showing 100 milliseconds for trace block, right? And then you had debug trace block at the top. That wasn't for live tracing, right? And then you had debug trace block at the top. That wasn't for live tracing, right? That was just historical calls where you can trace any block, correct? No, no, no. Actually, for trace tracing, you need to index the state force. Yeah, just after the guess is started. Right. Yeah. We got to cut it up here.",
- "eventId": "devcon-7",
- "slot_start": 1731469500000,
- "slot_end": 1731470400000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1seSZfQPsg8riFizMYXy6BWgpFjxQVJYELPyjZazrxIc",
- "resources_slides": null,
"speakers": [
- "jsvisa"
- ]
+ "hart-montgomery"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731649800000,
+ "slot_end": 1731651600000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1nEJvDuhtXFhZrplozdiBHSDSlr4Xbzxi2jSrYBCSPL8"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -442572,6 +441634,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -442900,17 +441963,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -443241,7 +442293,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -443274,6 +442325,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -443287,7 +442339,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -443330,7 +442381,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -443342,6 +442392,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -443576,6 +442627,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -443638,6 +442690,20 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -443786,7 +442852,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -443796,6 +442861,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -443808,36 +442877,35 @@
},
{
"session": {
- "id": "keynote-glass-houses-and-tornados",
- "sourceId": "K9A8EG",
- "title": "Keynote: Glass Houses and Tornados",
- "description": "The Tornado Cash sanctions and criminal prosecutions have challenged longstanding assumptions within crypto about the limits of money transmission licensing, money laundering statutes, and sanctions laws. They've also revealed a longstanding assumption from some in policy and law enforcement circles: that blockchains have always been and must remain transparent. Neither assumption has served us well and the time has come for legal certainty. This talk is about how we get there.",
- "track": "Cypherpunk & Privacy",
+ "id": "keynote-infinite-diversity-in-infinite-combinations",
+ "sourceId": "3MNMHA",
+ "title": "Keynote: ⿻ Infinite Diversity in Infinite Combinations",
+ "description": "This talk explores the evolving relationship between freedom, wisdom, and technology, centered on ⿻ Plurality—a philosophy that promotes collaborative diversity.\r\n\r\nDrawing on experiences from Taiwan and beyond, we’ll examine how decentralized governance can scale to bridge divides, empower autonomy, and co-create innovative solutions for the challenges of the 21st century.",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Lobby",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": true,
"doNotRecord": false,
"keywords": [
- "Legal",
- "Government",
- "Regulation"
+ "Plurality"
],
"tags": [
+ "Decentralization",
"Governance",
- "Mixers",
- "Open Source Software",
- "Privacy"
+ "Political systems"
],
"language": "en",
"speakers": [
- "peter-van-valkenburgh"
+ "audrey-tang"
],
"eventId": "devcon-7",
- "slot_start": 1731648600000,
- "slot_end": 1731649800000,
+ "slot_start": 1731389400000,
+ "slot_end": 1731391200000,
"slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1Xs3Tvj3iPf9ArWjPRjf3e7zXu_JG8R-eXuI5yEgHV6c"
+ "sources_youtubeId": "n3R4ze2hesk",
+ "sources_swarmHash": "7b57f594e589cebcc14cb04fcc90c7201ef214a347ba31c146c0fbe984a280ae",
+ "resources_presentation": "https://docs.google.com/presentation/d/1hyqMQ-ALTG3QKpk5SkiuUcDNN1L0Z_UuyGNml54Xc60"
},
"vector": [
0,
@@ -443845,8 +442913,8 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -444685,19 +443753,17 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -444708,7 +443774,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -444988,7 +444053,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -445153,16 +444217,17 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -445170,44 +444235,39 @@
0,
0,
0,
- 2
+ 0
]
},
{
"session": {
- "id": "keynote-how-to-properly-open-source-software-lessons-learned-from-the-linux-foundation",
- "sourceId": "MDHXHK",
- "title": "Keynote: How to Properly Open Source Software: Lessons Learned from the Linux Foundation",
- "description": "It can be challenging to properly open source software: there are licenses, IP, security reporting, and many other issues that need to be addressed. In this talk, we will discuss the best practices for open source software development learned from almost 25 years of experience at the Linux Foundation. Attendees will learn about how to set up their projects for a variety of potential goals, including things like maximizing security and community building.",
+ "id": "keynote-lessons-learned-from-tor",
+ "sourceId": "ZHU7UQ",
+ "title": "Keynote: Lessons learned from Tor",
+ "description": "I will share lessons learned during Tor's twenty years as free software fighting for privacy and human rights. We'll talk about distributed trust and privacy by design, how to help people understand the good uses of your tech, getting allies in both cypherpunks and government, why transparency and community-building are so essential to trust, and successes from other spaces. It may seem like the crypto wars never really end, but we all have a part to play in saving the world.",
"track": "Cypherpunk & Privacy",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Engineering",
"featured": true,
"doNotRecord": false,
"keywords": [
- "Linux Foundation",
- "Open Development"
+ "Human",
+ "rights"
],
"tags": [
- "Open Source Software",
- "FOSS",
- "Best Practices",
- "development",
- "open",
- "Best Practices",
- "FOSS",
- "Open Source Software"
+ "Anonymity",
+ "Privacy",
+ "Sustainability"
],
"language": "en",
"speakers": [
- "hart-montgomery"
+ "roger-dingledine"
],
"eventId": "devcon-7",
- "slot_start": 1731649800000,
- "slot_end": 1731651600000,
+ "slot_start": 1731651600000,
+ "slot_end": 1731653700000,
"slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1nEJvDuhtXFhZrplozdiBHSDSlr4Xbzxi2jSrYBCSPL8"
+ "resources_presentation": "https://docs.google.com/presentation/d/1kL3YxEdhVaztgX9zv7TsWTOPmhhTZ7zGvjBwWKxc__E"
},
"vector": [
0,
@@ -445300,9 +444360,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -445642,6 +444699,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -445987,13 +445045,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -446060,7 +445118,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -446078,6 +445135,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -446296,7 +445354,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -446311,6 +445368,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -446359,7 +445417,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -446527,9 +445584,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -446545,35 +445602,35 @@
},
{
"session": {
- "id": "keynote-infinite-diversity-in-infinite-combinations",
- "sourceId": "3MNMHA",
- "title": "Keynote: ⿻ Infinite Diversity in Infinite Combinations",
- "description": "This talk explores the evolving relationship between freedom, wisdom, and technology, centered on ⿻ Plurality—a philosophy that promotes collaborative diversity.\r\n\r\nDrawing on experiences from Taiwan and beyond, we’ll examine how decentralized governance can scale to bridge divides, empower autonomy, and co-create innovative solutions for the challenges of the 21st century.",
- "track": "Real World Ethereum",
+ "id": "keynote-make-ethereum-cypherpunk-again-why-we-need-privacy",
+ "sourceId": "NKMLNG",
+ "title": "Keynote: Make Ethereum Cypherpunk Again: Why we need privacy",
+ "description": "The Web3 revolution seeks to address the sins of Web2. However, in doing so, it’s created an even worse outcome for users - users’ data is publicly available and makes them vulnerable to state-level censorship and adverse actions.\r\n\r\nThis talk will address the philosophical as well as practical considerations of privacy in Web3. \r\nPrivacy is an industry-wide issue and sits at the heart of all that is Web3. Understanding why privacy matters involves recognizing that it is not an isolated concept bu",
+ "track": "Cypherpunk & Privacy",
"type": "Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Developer",
"featured": true,
"doNotRecord": false,
"keywords": [
- "Plurality"
+ "cypherpunk"
],
"tags": [
- "Decentralization",
- "Governance",
- "Political systems"
+ "Zk Rollups",
+ "Privacy",
+ "cypherpunk",
+ "Privacy",
+ "Zk Rollups"
],
"language": "en",
"speakers": [
- "audrey-tang"
+ "zac-williamson"
],
"eventId": "devcon-7",
- "slot_start": 1731389400000,
- "slot_end": 1731391200000,
+ "slot_start": 1731556800000,
+ "slot_end": 1731558600000,
"slot_roomId": "main-stage",
- "sources_youtubeId": "n3R4ze2hesk",
- "sources_swarmHash": "7b57f594e589cebcc14cb04fcc90c7201ef214a347ba31c146c0fbe984a280ae",
- "resources_presentation": "https://docs.google.com/presentation/d/1hyqMQ-ALTG3QKpk5SkiuUcDNN1L0Z_UuyGNml54Xc60"
+ "resources_presentation": "https://docs.google.com/presentation/d/1ReFBU_bsCAkpa9iAfYEJf0LER_SIpmsSyIlr2UIGBVw"
},
"vector": [
0,
@@ -446581,7 +445638,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -447005,11 +446061,9 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -447397,6 +446451,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -447424,17 +446479,14 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -447446,6 +446498,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -447710,6 +446763,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -447895,10 +446949,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -447911,34 +446965,35 @@
},
{
"session": {
- "id": "keynote-lessons-learned-from-tor",
- "sourceId": "ZHU7UQ",
- "title": "Keynote: Lessons learned from Tor",
- "description": "I will share lessons learned during Tor's twenty years as free software fighting for privacy and human rights. We'll talk about distributed trust and privacy by design, how to help people understand the good uses of your tech, getting allies in both cypherpunks and government, why transparency and community-building are so essential to trust, and successes from other spaces. It may seem like the crypto wars never really end, but we all have a part to play in saving the world.",
- "track": "Cypherpunk & Privacy",
+ "id": "keynote-making-sense-of-stablecoins",
+ "sourceId": "TDHR79",
+ "title": "Keynote: Making Sense of Stablecoins",
+ "description": "Everyone is talking about stablecoins now! In this talk I'll share what I learned about Tether on Tron in addition to stablecoins more broadly. Why are so many USDT transactions on Tron? Why did Bridge get acquired for $1.1B? What do L2s have to do with stablecoins? Are stablecoins a threat to Ethereum or an accelerant?",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": true,
"doNotRecord": false,
"keywords": [
- "Human",
- "rights"
+ "Stablecoins",
+ "Layer 2",
+ "RWA"
],
"tags": [
- "Anonymity",
- "Privacy",
- "Sustainability"
+ "Ethereum for Good",
+ "Payment",
+ "RWA"
],
"language": "en",
"speakers": [
- "roger-dingledine"
+ "liam-horne"
],
"eventId": "devcon-7",
- "slot_start": 1731651600000,
- "slot_end": 1731653700000,
+ "slot_start": 1731470400000,
+ "slot_end": 1731472200000,
"slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1kL3YxEdhVaztgX9zv7TsWTOPmhhTZ7zGvjBwWKxc__E"
+ "resources_presentation": "https://docs.google.com/presentation/d/1246DZFHYl7mJ0u_o2WRFQUGA1oxze-pQVaEpjC7wjPI"
},
"vector": [
0,
@@ -447946,9 +447001,8 @@
0,
0,
0,
- 6,
- 0,
0,
+ 6,
0,
0,
0,
@@ -448266,6 +447320,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -448371,7 +447426,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -448719,7 +447773,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -448809,7 +447862,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -448819,6 +447871,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -448833,6 +447886,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -448845,6 +447899,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -449043,7 +448098,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -449258,11 +448312,9 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
+ 2,
0,
0,
0,
@@ -449276,43 +448328,42 @@
},
{
"session": {
- "id": "keynote-make-ethereum-cypherpunk-again-why-we-need-privacy",
- "sourceId": "NKMLNG",
- "title": "Keynote: Make Ethereum Cypherpunk Again: Why we need privacy",
- "description": "The Web3 revolution seeks to address the sins of Web2. However, in doing so, it’s created an even worse outcome for users - users’ data is publicly available and makes them vulnerable to state-level censorship and adverse actions.\r\n\r\nThis talk will address the philosophical as well as practical considerations of privacy in Web3. \r\nPrivacy is an industry-wide issue and sits at the heart of all that is Web3. Understanding why privacy matters involves recognizing that it is not an isolated concept bu",
- "track": "Cypherpunk & Privacy",
+ "id": "keynote-nomic-foundations-vision-for-ethereums-tooling-ecosystem",
+ "sourceId": "VQKXUH",
+ "title": "Keynote: Nomic Foundation’s vision for Ethereum’s tooling ecosystem",
+ "description": "Nomic Foundation is the nonprofit behind Hardhat. Nomic’s co-founder and CTO will walk you through Nomic’s long-term vision for a community-driven developer tooling ecosystem for Ethereum.",
+ "track": "Developer Experience",
"type": "Talk",
- "expertise": "Beginner",
+ "expertise": "Intermediate",
"audience": "Developer",
"featured": true,
"doNotRecord": false,
"keywords": [
- "cypherpunk"
+ "ecosystem"
],
"tags": [
- "Zk Rollups",
- "Privacy",
- "cypherpunk",
- "Privacy",
- "Zk Rollups"
+ "Developer Infrastructure",
+ "DevEx",
+ "Tooling"
],
"language": "en",
"speakers": [
- "zac-williamson"
+ "patricio-palladino"
],
"eventId": "devcon-7",
- "slot_start": 1731556800000,
- "slot_end": 1731558600000,
+ "slot_start": 1731567600000,
+ "slot_end": 1731569400000,
"slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1ReFBU_bsCAkpa9iAfYEJf0LER_SIpmsSyIlr2UIGBVw"
+ "resources_presentation": "https://docs.google.com/presentation/d/1kH4iHwoLEeXM3eu44ZJv-USuH2XZbecC-mTN78JbaFE"
},
"vector": [
0,
0,
0,
+ 6,
+ 0,
0,
0,
- 6,
0,
0,
0,
@@ -449686,6 +448737,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -449738,7 +448790,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -450076,6 +449127,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -450084,6 +449136,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -450107,6 +449160,18 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -450128,7 +449193,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -450175,7 +449239,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -450441,19 +449504,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -450617,6 +449667,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -450626,10 +449677,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -450642,35 +449689,42 @@
},
{
"session": {
- "id": "keynote-making-sense-of-stablecoins",
- "sourceId": "TDHR79",
- "title": "Keynote: Making Sense of Stablecoins",
- "description": "Everyone is talking about stablecoins now! In this talk I'll share what I learned about Tether on Tron in addition to stablecoins more broadly. Why are so many USDT transactions on Tron? Why did Bridge get acquired for $1.1B? What do L2s have to do with stablecoins? Are stablecoins a threat to Ethereum or an accelerant?",
- "track": "Real World Ethereum",
+ "id": "keynote-programmable-cryptography-and-ethereum",
+ "sourceId": "MQ8T8Z",
+ "title": "Keynote: Programmable Cryptography and Ethereum",
+ "description": "Programmable Cryptography is a \"second generation\" of cryptographic primitives - primitives that allow arbitrary programs to be executed \"inside of\" or \"on top of\" cryptographic objects. Programmable cryptography provides three key affordances that complement and amplify the affordances of Ethereum--verifiability, confidentiality, and non-interactivity. We'll discuss how these technologies can reshape the Internet over the next 50 years.",
+ "track": "Applied Cryptography",
"type": "Talk",
"expertise": "Beginner",
- "audience": "Product",
+ "audience": "Engineering",
"featured": true,
"doNotRecord": false,
- "keywords": [
- "Stablecoins",
- "Layer 2",
- "RWA"
- ],
"tags": [
- "Ethereum for Good",
- "Payment",
- "RWA"
+ "Cryptography",
+ "Use cases of cryptography"
],
- "language": "en",
- "speakers": [
- "liam-horne"
+ "keywords": [
+ "Programmable",
+ "Cryptography"
],
+ "duration": 1517,
+ "language": "en",
+ "sources_swarmHash": "e13e6bd7be8fffa7336eb9daa88cf857ddb07345077867d9a45fa4fda0586ac9",
+ "sources_youtubeId": "UWPg_AmWtlw",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733199b3a168eb5351198a0.vtt",
+ "transcript_text": " Awesome. It's great to see everyone at DevCon. Thank you all for coming. Today I'm going to be talking about programmable cryptography and Ethereum. As a quick introduction, I'm Gubsheep. I'm one of the co-founders of 0xPark. We're an organization that emerged out of the Ethereum ecosystem about three years ago. And since we first coined the term programmable cryptography in 2022, we've been working to accelerate the development of the field from a technical ecosystem and conceptual perspective. Our goal is to take programmable cryptography from research to production and to harness its powers for a new digital universe. A lot of this talk will center around the following question. How do we compute together? Specifically, how do we, as in a group of multiple people, perform a computation or execute a program together? Now, to give some context on this question, I want to take us back about 30 or 40 years to the earliest days of the internet. In the beginning, the internet was a peer to peer network for essentially transmitting bits between equal peers. This means that you could do things like send a document to another IP address using protocols like FTP or SMTP. At this point, there was not yet any notion of web servers as we traditionally think about them today or the client server model. Rather, the internet, instead of being an answer to the question of how do we compute together, was more of a peer-to-peer network for communicating together. But computing is something much more than that. And pretty early on, people started to realize that it's useful to be able to do more than just send data back and forth. It would be useful to be able to run programs on this data that's being passed around on the internet. But with the existing setup of the internet in the early days, there was a problem. In the days of the early internet, the ability to compute was limited to individual machines running programs over their own data. So you could only run a program over data that lives physically on your own device. You know, that makes sense. So most apps looked like single-player programs. Imagine games like Solitaire, you know, a single-player game, or something like Flappy Bird, or tools like spreadsheets or word processors or photo editing tools or a calculator that just runs locally on your own device. But of course we wanted to do more. We wanted to compute together and have services like marketplaces or ride-sharing apps or social networks or massively multiplayer games or global payment systems or dating apps or all sorts of things. And so we came up with a way of sort of simulating this idea of computing together, while in reality we were actually still sticking to the single-player compute model. And that first solution, the strategy for the last 30 years, has been to pick one very important node, like Dave over here in the middle, and to promote Dave such that we all give Dave all of our data. And now Dave can basically run something like the Facebook backend as if it was a single player application running just on Dave's machine. So this has been the status quo for many decades. And from this example, we can sort of see why servers came to exist in the first place. Web servers do several things that individuals and pure peer-to-peer networks like the early internet can't do alone. Web servers allow us to coordinate on and perform computations over multiple people's state. That state might be private to some particular subset. It might be public. It allows us to decide which state is canonical and web servers also provide strong uptime and liveness guarantees that don't necessarily exist in a peer to peer network. So um this has taken us pretty far but uh you know one question is is can we do better right? There's been a lot of problems that have arisen as a result of this being the fundamental architecture. And in fact, these problems are a big part of why many of us today are in this room. You can feel free to choose the problems you care about. There's all sorts of things. And when we return back to the question then of how do we compute together, we have to ask, is there a better way that we could go about this? And one of the really interesting discoveries of the last decade is that blockchains, crypto economics, and Ethereum have given us new answers to this question for the first time in decades. So now, Ethereum allows us to run a single computer collectively in a way that's sort of very different than the traditional model where we promote that one single node, Dave, to be a very important node that we give all of our data to. So Ethereum has given us extraordinary things, you know, many of which we saw this morning. Because we have the ability to have decentralized consensus over global state, we have neutral and autonomous marketplaces, financial derivatives, prediction markets, we have payment systems that no single authority controls, we have permissionless identity registries spinning up, we have interoperable and composable games. Um but we also can't do everything that we want yet. In fact nearly everything that I showed on the previous slide is still beyond the capabilities of Ethereum alone. And not just as a result of performance, but as a result of fundamental architecture and capability limitations. So enter programmable cryptography. Programmable cryptography is a technology that can give us many more answers to the question of how do we compute together. And it can give us these answers both independently and in combination with Ethereum. So what is programmable cryptography? For those of you who aren't familiar with the term, programmable cryptography refers to a second generation of cryptographic primitives that have started to emerge and become viable in the past two to five years.",
"eventId": "devcon-7",
- "slot_start": 1731470400000,
- "slot_end": 1731472200000,
+ "slot_start": 1731398400000,
+ "slot_end": 1731400200000,
"slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1246DZFHYl7mJ0u_o2WRFQUGA1oxze-pQVaEpjC7wjPI"
+ "resources_presentation": "https://docs.google.com/presentation/d/1xCnHIn3N6_CE75tyV-Jo2eMU07wZIBXFedFxwrk7xf4",
+ "resources_slides": null,
+ "speakers": [
+ "gubsheep"
+ ]
},
"vector": [
0,
@@ -450679,13 +449733,11 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -450857,6 +449909,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -450998,7 +450051,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -451437,6 +450489,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -451451,6 +450504,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -451551,7 +450605,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -451566,7 +450619,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -451579,7 +450631,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -451990,11 +451041,11 @@
0,
2,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -452008,48 +451059,59 @@
},
{
"session": {
- "id": "keynote-nomic-foundations-vision-for-ethereums-tooling-ecosystem",
- "sourceId": "VQKXUH",
- "title": "Keynote: Nomic Foundation’s vision for Ethereum’s tooling ecosystem",
- "description": "Nomic Foundation is the nonprofit behind Hardhat. Nomic’s co-founder and CTO will walk you through Nomic’s long-term vision for a community-driven developer tooling ecosystem for Ethereum.",
- "track": "Developer Experience",
+ "id": "keynote-the-next-10-years-of-web3-in-africa",
+ "sourceId": "GSNQLC",
+ "title": "Keynote: The next 10 years of Web3 in Africa",
+ "description": "When Africa reaches 2 billion people, what are the profound ways Web3 shapes its economy? Historically, millions of Africans repurposed and stitched together crypto tools for real-world utility. Now, a new generation of builders is developing tailored solutions. In the next 10 years, what can we expect to be built that redefines trust and finance in Africa? And what needs to be true for more than half of African economies to be powered by decentralized technologies?",
+ "track": "Real World Ethereum",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Product",
"featured": true,
"doNotRecord": false,
- "keywords": [
- "ecosystem"
- ],
"tags": [
- "Developer Infrastructure",
- "DevEx",
- "Tooling"
+ "Ethereum Roadmap",
+ "Use Cases",
+ "macro/micro economics",
+ "adoption",
+ "africa",
+ "mass",
+ "Ethereum Roadmap",
+ "macro/micro economics",
+ "Use Cases"
],
- "language": "en",
- "speakers": [
- "patricio-palladino"
+ "keywords": [
+ "Africa",
+ "Mass adoption",
+ ""
],
+ "duration": 1531,
+ "language": "en",
+ "sources_swarmHash": "2415d9c9f111fd9ab297194c0cc7b8de5a938accb641bfdb907c2ca01e0958d3",
+ "sources_youtubeId": "NtkNYNvuu6w",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733f64b3a168eb53542528d.vtt",
+ "transcript_text": " Leonardo Silva Reviewer:\" Elisabeth Buffard Hello everyone. Good to see you all today. I want to start off by asking who is here from the continent of Africa. Can you please raise your hand? Can you guys please stand up? Can you guys please stand up? Let's give this guy a big round of applause because like many of our folks have gone through crazy lengths to get themselves here with visas and everything. And this is the DEF CON that has the largest African builder concentration in one place. And my talk today is around what can we expect over the next 10 years in terms of crypto innovation and is very much inspired by a lot of what I've learned from all these folks and many more of what are the things that have been built today and what can we expect coming up. So two years ago at DEF CON, we established the fact that it's actually the crypto ecosystem that needs Africa to reach its full potential of reaching mass adoption and utility-driven building to scale it to billions of people. And we covered the fact that we are the most populous part of the world and we're growing really fast. That is going to be where all the young people in the world are going to be based at even today we have about 600 million Africans who are the end under the age of 14 that's out of 1.5 billion people and we also discussed around the technology rails that exist that how allowed us to basically skip generations of innovations such as mobile phones skipping landlines or mobile money where that has close to trillion dollars worth of transactions a year and we're jumping traditional banking with crypto. Two years ago when we discussed a lot of this, what was the reality is that mostly many of us were doing crypto to fiat transactions doing payments savings and storing resources or investing using predominantly centralized exchanges and a lot of centralized exchanges are actually not made to be banks they're trading platforms but we kind of figured a way to do that by having various liquidity providers like people like you and I providing liquidity on peer-to-peer their trading platforms. But we kind of figured a way to do that by having various liquidity providers like people like you and I, providing liquidity on peer-to-peer exchanges to drive a lot of the value for normal people to access traditional forms of banking that we need. So where are we today, two years from then? Well, the one reality is that in the traditional world we're still in the same place, that we are communicating value over walls, that the internet, as amazing as it's been at connecting us and letting communication flow, communication of value, which is through monetary systems, are actually very much gated. The internet continues to be very gated. The same way back in the days you would have an operator basically connecting two calls by manually calling the other side and seeing can we trust the other operator. That's the same process that we have today. So we are still working through walls in the traditional system. The other aspect of where we still are today is that a huge part of our economy is happening in the informal sector. That includes our GDP, our prominent GDP is backed by micro enterprises. A huge part of our employment is in the informal economy. A huge part of our GDP is also drive by the informal economy. A huge part of our GDP is also drived by the informal economy and also a lot of our money movement happens outside of the banking system. This is a very important context for us to understand why crypto is thriving so much on the continent. Another big also lens is that we have a systemic US dollar problem. Some of these numbers are a bit outdated but we're importing more than what we're exporting we're taking a lot of debt a lot of african countries debt has doubled in the last 10 years and we're paying that debt plus interest in dollars and we're trading with each other as neighbors using dollars and when our currencies fluctuate so much, then we move our money to dollars. So that creates a demand supply. And on the supply pressure, we have a lot of exports, remittance, people sending money. There's a thing called BRIC. Some of you guys might know about it. Around some countries deciding to settle outside of the dollar system, which is creating a bit less pressure on the dollar. And there's a lot of aid and loans that come in dollars. So what is the consequence of this? Is that basically the US dollars are being rationed by the central banks. The demand for dollars is higher than what they have there. So what you end up having is the bifurcation of the bank rate and the black market rate, or how I call it, the actual market rate um and in worse economies you see that being very large in well-managed economies it's very small but we're living in in parallel systems and also that makes the dollar a commodity so people do unnatural things in order to access dollars because the upside on trading the dollar is higher than the trade on the commodity itself, which creates very weird dysfunctions in our system. And some countries have also created rules of who can own dollars and how much you can transfer it. Until very recently, the Ethiopian government actually made it illegal, meaning you can go to prison for it, for holding more than $500 with you at any given point. Many of my friends' and family's houses were raided, just people looking for dollars. And that's because the central banks don't have enough dollars. And what that means, we borrow more money and then just rinse and repeat. So we have a systemic dollar problem. And so you look at that and say, okay, well, what is crypto doing? Well, fundamentally, what crypto has provided us is basically a digital version of the dollar, US dollar stable coins, that allow for large-scale liquidity coordination mechanism in the informal economy, where a lot of dollars have been circulating physically or through various networks like the Hawala networks that call each other and basically move numbers around. What has that allowed us is basically for early stage startups to be able to aggregate more liquidity than what a bank can in a very short period of time and then settle that payment in a much shorter period of time. And this has been a fundamental value proposition of crypto. So as a result of that, crypto has been thriving, it's been growing. Even in the bear market, crypto transactions have been growing on the continent. Chainalysis says we've had $125 billion worth of transactions last year. When I talk to the analysts and the builders, that's just the tip of the iceberg. There's much more dollars that's been transacted behind that. Nigeria of course is the second most popular place for crypto. And Nigeria, Ethiopia, Kenya, we search crypto online because it is solving fundamental problems for us. But this is not just centralized exchanges. This is happening in other rails that have been built. So actually, some of the builders here in this room have built some of these stacks. These are from the builders in Magma, from wallet infrastructure. So actually making like SDK wallets that you can embed into your fintech application or your crypto application. So you can use crypto and fiat. Aggregating liquidity on-chain and off- off chain which is actually not very easy to do and and simplify the on and off run process through that different types of wallets that are being created and all types of payments from b2b b2c b2b b2c serving like small businesses medium, medium-sized businesses, oil and gas companies, and even banks and payment service providers who are now using these startups to facilitate international payments. And people even issuing debit cards on top of your digital wallet in order to be able to pay online without having any limitations, because some of our banks say, I'm so sorry, you can only pay $10 a month. Well, if you have some resource, you want to buy a book from Amazon, how can you buy it with $10? Amazon is more expensive than that. So you're actually using crypto projects in order to do that. And so some of these projects are way advanced than where I see a lot of on and off ramps. And so, bluntly speaking, if DEF CON was held in one of the countries that were mentioned in Africa, the DEF CON organizing team can pay all their bills using crypto. All of us would basically be using our crypto to make payments with fiat without even needing a fiat wallet paying directly just using the applications that have been built today so there's been a lot of work that has happened in terms of making the user experience a lot easier and if you're curious about it just talk to many of the builders who are in this room so with that in mind what can we expect in the next 10 years what are some of the innovations that we can expect to have? Well, fundamentally, I think the most interesting part of crypto to me is bringing whole economies and powering them by decentralized systems. Part of that is basically changing the foundations of our existing economy, and part of it is like opening up new economic activities that we did not know existed before um and this is where i think ethereum comes in because that's the most robust and the most resilient decentralized system that we have right now so it's it's a beautiful merge here and when we think about rewriting a lot of the foundations of our economies we've got to think about both hyper globalizationglobalization and hyper-localization. We talked a lot about US dollar stablecoins, right? So the answer is not, let's dollarize the entire African economy. Everyone uses dollars, dollars for everyone. That's not the answer. I don't think that helps us and it doesn't help the global economy. So we've got to also think very locally. And one idea I'd love to dive deeper on is this idea of actually local currency stable coins. At the moment, when we think about stable coins, it's kind of synonymous with US dollar stable coins. How about actually having our Kenyan, Nigerian shillings, Nigerian naira, Ethiopian burr, a lot of our local currencies having a digital version of them on-chain. What does that allow? Well, on-chain forex. That makes it a lot more efficient. We'll double-click on that. Cheaper local payments. In a crazy way today, with blobs, it is cheaper to run transactions on a layer 2 at least 5 to 10 times than it is on mobile money or banking, which is quite crazy. Well, that doesn't mean blobs will scale infinitely, but it's just an interesting data point of what we can even do today. And the last part of the value here that we can think of at this stage is that it gives us programmable money, and that opens up a whole lot of opportunities and innovations that can happen. I really want to double click on the on-chain forex. Well today Kenya and Tanzania are neighboring countries right next to each other. We even speak similar languages and both our currencies are called shillings. But in order to make a payment from Kenya to Tanzania you actually have to convert it to the dollar. Dollar has to go through the trade system. It has to flow through London or New York or somewhere. It can take a few days, and depending on the volume, it can take even weeks. It's a very long process and long system. It doesn't make sense that we're having to do this as neighbors, right? With local stablecoins, you could potentially move from the Canadian shilling stablecoin to a Tanzanian shilling stable coin, both denominated in value against the dollar, but not actually touching the dollar. So this helps us move the US dollar from just being a medium of exchange to being a unit of account, which is a very interesting use case for it. So one way that can work is building a pair of liquidity where an importer is putting money into the pool from the Kenyan side and an exporter is pulling money out of it. And the person does the exact same thing on the Tanzanian front. And because every trade does not fully balance, you use dollars to basically rebalance the pool by adding local currency on the other side. This is just one model. I am sure we can come up with way more complex and more interesting models to structure this. But bringing forex on chain is one of the most interesting problems for us to solve using local stable coins. Now, when we think about that, we can think in a few million dollar value, or we can think about half economies. And I think the most important thing that we keep missing in the space when we look at the full potential of crypto is that we're not always looking at how can half an economy run on what we're building, and what needs to be true for us to get there. And the reason why I'm saying that is because, you know, many of you know M-Pesa, right? M-Pesa is one of the best success stories that has come out of Kenya. Half the Kenyan economy runs on M-Pesa. What M-Pesa is, is just a private ledger. It's a spreadsheet where they put some fiat in the bank, and the numbers move from different account names and at the end of the day it's basically settled at the bank layer that's somehow a version of what we're talking about but what we're talking about is putting that on chain and a much more open transparent system right for us to get to that level of scale at a much faster period we've got to think about from different principles and and one lens that I can think of is using government bonds to back our local stable coins. You convert the local bond into a real world asset that can either be fully collateralized through a CDP or a better model that we can come up with. And by the way, if you do, I'd love to chat with you. And basically use that to distribute local currency through existing and new rails around. The forex on-chain is one of the lowest-hanging fruit examples of where we can go, but we can bring so many other values to that. And in the future, it doesn't just need to be government bonds to do this. We can bring other types of assets assets like local land, productive land or protected land or gold and silver and precious metals. We're generating so much of that from Africa at the moment. Or we can do other types of commodities. This is such an open book in terms of what we back our local currencies with. Another pillar after local stablecoins that I love to chat about is simple finance as a stack. Now, here in the Ethereum world, we talk about decentralization a lot. Well, for us on the continent, decentralization is actually a very practical solution to a very practical problem. We have a lot of banking rails to build for hundreds of millions of people, and many of them have not been born yet. To do that, trying to build that in a monolithic way as a centralized company, as one piece, like Alipay or WeChat or Grab for 54 jurisdictions, and scale that in a very short period of time is almost impossible to execute. So the best way for us to do that that in a very short period of time, is almost impossible to execute. So the best way for us to do that, in my view, is just to build a connected web of tools. Different pieces of the Lego that form a financial stack that come together, that offer users a better experience and better options, right? I think building this in a much more decentralized way, to me, is the only way we can get to the level of scale that we need to achieve. So for us, it's actually a very practical solution, a practical way of getting there. And we can build interoperable monies with network effects. Remember the walls, the operator? We can just bypass that and keep moving value across different populations and people in that way. Create cash apps with simple user experience powered by crypto, but we don't even have to know that it's crypto. Today we have startups that are doing that, but we can scale that to infinity. And on the hyper-localization lens, there are many ways we can build around existing trust structures. Across many African countries, we have basically cooperatives and little communities of people. Some of us call them table banking, some of us call them chamas, where basically people pull money together to save and lend to each other. There's a strong trust infrastructure that exists to enable things like that. We don't have to reinvent trust from scratch. We can leverage those existing trust structures to build very resilient, hyper-local economies. And I think that should be part of our roadmap. And beyond, you know, so ultimately, it's just two people or two companies or two agents having normal financial transactions, right? No complexity, not much. We're not talking about crypto at the front end. This is all enabling that. Other areas of innovation that we can think about is like around credentialing, identity, reputation, credit scoring, bringing things that don't exist on chain to create trust on chain are some of the more interesting areas for us to experiment on. We don't have time to dive deep into many of these, and there's a lot more than other areas of innovation that we can build in the next 10 years, but talk to the builders around the table. And the other areas bringing assets on chain, such as real estate. We talked about bonds earlier, but different types of commodities, energy, power generating structures that we need to fund and actually revenue generating. We can experiment with so many of these that actually powers the fundamentals of our economies. So with all these ideas and directions that we can go, you might be wondering, how do I help? How do I connect? How do I participate in this? Well, the first is it's an invitation. It's actually an invitation because there's a lot of building happening on the continent, whether we have a lot of builders coming to DEF CON or not. So it's an invitation for you all from infrastructure, from research, from different ecosystems and chains, from capital allocation, from mentorship and support, from actually working with some of the smartest people on the planet. There are many ways you can plug it into the movement that is happening in Africa. And of course, why not bring DEF CON to Africa in two years' time? Who's down for something like that here? Right? Well, yeah, I think that would be super cool, and you guys will have a blast joining DEF CON there. But it's actually not about having another big event on the continent. It's actually, it gives you a much deeper context to go and see this in practice. It is very, very hard to explain how broken the world gardens are until you actually go and experience it in person. Or it's very hard for me to explain to you like what seamless user experience for crypto looks like without actually going and experiencing and making a whole lot of payments and living your life using your crypto wallet without touching physical bills, right? So it's an invitation for you to actually be part of the movement and work that we have. And lastly, because all the Ethereum events that have happened around the world have happened in places where it's just very hard to get visas, right. So to get 177 folks here, man, that was like a lot of work and it's been a lot of collective effort. And there are hundreds and thousands more that you would absolutely enjoy connecting with and learning with and learning from. And so you're invited home. Welcome, guys. All right. That was an awesome presentation, you guys. We have a Q&A session. So anyone want to put a question, that's the QR right there. Just scan it and put a question there. We have a lot for you, brother. Yes. Let's take a look at which one you want to answer first. We can talk about the non-financial use cases. We can talk about the non-financial use cases. We talked about them later on. Yeah, this talk focused a lot on finance because it's just a lot to unpack. And each topic that we talked around, credentialing, around bringing assets on-chain, and credit scoring, and gaming, and communication, there's a lot to unpack there. I will actually invite you guys to talk to some of our builders here to understand a lot of the nuances. But at the moment, 500 million Africans don't have any form of legal ID. And the best that some of our countries are doing is basically having a data center in one location or two locations and putting the entire population's data there. It's like a honeypot of sovereign data. That's not the most secure way to do it, in my opinion. the entire population's data there. It's like a honeypot of sovereign data, right? That's not the most secure way to do it, in my opinion. So I think there's a lot of ways we can innovate around that. KYC is one that really came up, like transferable KYC across multiple tools. So the list goes on. So the invitation is to actually talk to the builders in the room. Any questions you want to answer? We have a lot more here. All right. What do you see Africa becoming? What do you see Africa becoming a well-coordinated roadmap? I want to talk about regulation. All right, let's go. Because that continues to be a hot topic. And it's really important to us because many of our innovations are interfacing the traditional world with the crypto world because that that door needs to be very fluid it needs to allow money to keep moving back and forth for a long period of time and until we bring it on chain um and i think that's a that's a very important problem so i talked to a bunch of regulators many of the builders here talk to many regulators there's there's curiosity, there's some fear because crypto can be a path for capital flight. A lot of value to live in a short period of time. And that's an actual risk. And some of them don't even understand the fundamentals of this technology. So what we end up having is some countries like South Africa saying, crypto is legal. It's a commodity. We will allow it and so we have a lot of builders working there some countries creating environments for experimentation like sandboxes and actually this is a bit of a controversial view but I think creating some sort of tax revenue from crypto transactions for governments is a potentially positive thing if it's done well, because it moves this category from a risk basis to an income generating category. And bringing local stable coins on chain is, I think, one of the biggest value props for governments, because what it does is it creates a much more efficient capital markets for dollars and bonds it brings dollars in and helps reduce the dollar pressure for local trade that can happen so they have an incentive to see something like that but there's a lot of people here doing the hard work of actually informing regulators and we keep building like we keep building even with gray area we keep building like the show doesn't stop. And I think that's something some of us in, like, the Western world find it hard to kind of navigate around, is because, like, even when Nigeria makes crypto illegal, like, we still have close to 15% of the country's GDP, like, proportion transactions happening in crypto, right? So, yeah, it makes you kind of wonder what some of those kind of guidelines can actually have an effect. I think we have about one or two questions more. Let's see what we want to answer. Am I hiring? Are you hiring? I mean, I don't know, guys. We can jam outside after this and recruit more folks to help answer the question. But yeah, I guess what needs to happen before a DEF CON happens there is there's a lot we've got to do on the continent. We have many communities doing real work. They need a lot of support and engagement. So I think that will bring a lot of value. We need to have more hackathons and builders. But, like, I think our builder community, like, the startups that we have there are, from a user experience perspective, in my opinion, are, like, way ahead from what we keep talking about around usability making crypto usable for daily life like whenever I'm in many African countries like I don't use my card, I don't use cash I'm just like paying all types of bills using my crypto account and I think that's super cool and that's amazing so like even the bill of community alone is enough to host you all. All right. Give a round of applause for the speaker. Thank you.",
"eventId": "devcon-7",
- "slot_start": 1731567600000,
- "slot_end": 1731569400000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1kH4iHwoLEeXM3eu44ZJv-USuH2XZbecC-mTN78JbaFE"
+ "slot_start": 1731407400000,
+ "slot_end": 1731409200000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1IAQR41JAk7FPn24OGhprL4uyoP17OlBMG8dv6oyQ_n8",
+ "resources_slides": null,
+ "speakers": [
+ "yoseph-ayele"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -452418,7 +451480,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -452427,6 +451488,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -452810,7 +451872,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -452819,7 +451880,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -452843,7 +451903,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -452874,6 +451933,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -452952,6 +452012,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -452984,6 +452046,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -453004,6 +452067,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -453187,6 +452251,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -453356,9 +452421,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -453372,41 +452437,47 @@
},
{
"session": {
- "id": "keynote-programmable-cryptography-and-ethereum",
- "sourceId": "MQ8T8Z",
- "title": "Keynote: Programmable Cryptography and Ethereum",
- "description": "Programmable Cryptography is a \"second generation\" of cryptographic primitives - primitives that allow arbitrary programs to be executed \"inside of\" or \"on top of\" cryptographic objects. Programmable cryptography provides three key affordances that complement and amplify the affordances of Ethereum--verifiability, confidentiality, and non-interactivity. We'll discuss how these technologies can reshape the Internet over the next 50 years.",
- "track": "Applied Cryptography",
+ "id": "keynote-the-real-state-of-l2s",
+ "sourceId": "HCXUU8",
+ "title": "Keynote: The REAL state of L2s",
+ "description": "The evolution of Layer 2 solutions has been pivotal in scaling blockchain technologies. This talk, led by L2BEAT founder Bartek Kiepuszewski, delves into the current landscape, recent advancements, and future potential of L2 ecosystems. It will try to address some myths and current challenges of the space. Some important changes to L2BEAT risk framework will also be announced.",
+ "track": "Layer 2",
"type": "Talk",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": true,
"doNotRecord": false,
"tags": [
- "Cryptography",
- "Use cases of cryptography"
+ "Architecture",
+ "Layer 2s",
+ "Best Practices",
+ "myths",
+ "reality",
+ "Architecture",
+ "Best Practices",
+ "Layer 2s"
],
"keywords": [
- "Programmable",
- "Cryptography"
+ "L2Risks",
+ "Myths&Reality"
],
- "duration": 1517,
+ "duration": 1530,
"language": "en",
- "sources_swarmHash": "e13e6bd7be8fffa7336eb9daa88cf857ddb07345077867d9a45fa4fda0586ac9",
- "sources_youtubeId": "UWPg_AmWtlw",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "GJ1L2dBkrWE",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733199b3a168eb5351198a0.vtt",
- "transcript_text": " Awesome. It's great to see everyone at DevCon. Thank you all for coming. Today I'm going to be talking about programmable cryptography and Ethereum. As a quick introduction, I'm Gubsheep. I'm one of the co-founders of 0xPark. We're an organization that emerged out of the Ethereum ecosystem about three years ago. And since we first coined the term programmable cryptography in 2022, we've been working to accelerate the development of the field from a technical ecosystem and conceptual perspective. Our goal is to take programmable cryptography from research to production and to harness its powers for a new digital universe. A lot of this talk will center around the following question. How do we compute together? Specifically, how do we, as in a group of multiple people, perform a computation or execute a program together? Now, to give some context on this question, I want to take us back about 30 or 40 years to the earliest days of the internet. In the beginning, the internet was a peer to peer network for essentially transmitting bits between equal peers. This means that you could do things like send a document to another IP address using protocols like FTP or SMTP. At this point, there was not yet any notion of web servers as we traditionally think about them today or the client server model. Rather, the internet, instead of being an answer to the question of how do we compute together, was more of a peer-to-peer network for communicating together. But computing is something much more than that. And pretty early on, people started to realize that it's useful to be able to do more than just send data back and forth. It would be useful to be able to run programs on this data that's being passed around on the internet. But with the existing setup of the internet in the early days, there was a problem. In the days of the early internet, the ability to compute was limited to individual machines running programs over their own data. So you could only run a program over data that lives physically on your own device. You know, that makes sense. So most apps looked like single-player programs. Imagine games like Solitaire, you know, a single-player game, or something like Flappy Bird, or tools like spreadsheets or word processors or photo editing tools or a calculator that just runs locally on your own device. But of course we wanted to do more. We wanted to compute together and have services like marketplaces or ride-sharing apps or social networks or massively multiplayer games or global payment systems or dating apps or all sorts of things. And so we came up with a way of sort of simulating this idea of computing together, while in reality we were actually still sticking to the single-player compute model. And that first solution, the strategy for the last 30 years, has been to pick one very important node, like Dave over here in the middle, and to promote Dave such that we all give Dave all of our data. And now Dave can basically run something like the Facebook backend as if it was a single player application running just on Dave's machine. So this has been the status quo for many decades. And from this example, we can sort of see why servers came to exist in the first place. Web servers do several things that individuals and pure peer-to-peer networks like the early internet can't do alone. Web servers allow us to coordinate on and perform computations over multiple people's state. That state might be private to some particular subset. It might be public. It allows us to decide which state is canonical and web servers also provide strong uptime and liveness guarantees that don't necessarily exist in a peer to peer network. So um this has taken us pretty far but uh you know one question is is can we do better right? There's been a lot of problems that have arisen as a result of this being the fundamental architecture. And in fact, these problems are a big part of why many of us today are in this room. You can feel free to choose the problems you care about. There's all sorts of things. And when we return back to the question then of how do we compute together, we have to ask, is there a better way that we could go about this? And one of the really interesting discoveries of the last decade is that blockchains, crypto economics, and Ethereum have given us new answers to this question for the first time in decades. So now, Ethereum allows us to run a single computer collectively in a way that's sort of very different than the traditional model where we promote that one single node, Dave, to be a very important node that we give all of our data to. So Ethereum has given us extraordinary things, you know, many of which we saw this morning. Because we have the ability to have decentralized consensus over global state, we have neutral and autonomous marketplaces, financial derivatives, prediction markets, we have payment systems that no single authority controls, we have permissionless identity registries spinning up, we have interoperable and composable games. Um but we also can't do everything that we want yet. In fact nearly everything that I showed on the previous slide is still beyond the capabilities of Ethereum alone. And not just as a result of performance, but as a result of fundamental architecture and capability limitations. So enter programmable cryptography. Programmable cryptography is a technology that can give us many more answers to the question of how do we compute together. And it can give us these answers both independently and in combination with Ethereum. So what is programmable cryptography? For those of you who aren't familiar with the term, programmable cryptography refers to a second generation of cryptographic primitives that have started to emerge and become viable in the past two to five years.",
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731398400000,
- "slot_end": 1731400200000,
+ "slot_start": 1731472200000,
+ "slot_end": 1731474000000,
"slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1xCnHIn3N6_CE75tyV-Jo2eMU07wZIBXFedFxwrk7xf4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1NxPv65UP8MJMX2f8NWmiAL-GETRNifiDtkZS5evBvV0",
"resources_slides": null,
"speakers": [
- "gubsheep"
+ "bartek-kiepuszewski"
]
},
"vector": [
@@ -453417,9 +452488,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -453593,53 +452661,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -453891,6 +452912,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -454175,7 +453197,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -454190,7 +453211,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -454241,6 +453261,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -454271,9 +453292,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -454451,6 +453474,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -454604,6 +453628,47 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -454725,7 +453790,6 @@
0,
0,
0,
- 2,
0,
2,
0,
@@ -454736,6 +453800,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -454745,50 +453813,33 @@
},
{
"session": {
- "id": "keynote-the-next-10-years-of-web3-in-africa",
- "sourceId": "GSNQLC",
- "title": "Keynote: The next 10 years of Web3 in Africa",
- "description": "When Africa reaches 2 billion people, what are the profound ways Web3 shapes its economy? Historically, millions of Africans repurposed and stitched together crypto tools for real-world utility. Now, a new generation of builders is developing tailored solutions. In the next 10 years, what can we expect to be built that redefines trust and finance in Africa? And what needs to be true for more than half of African economies to be powered by decentralized technologies?",
- "track": "Real World Ethereum",
+ "id": "keynote-the-universal-cryptographic-adapter",
+ "sourceId": "R9X9ZG",
+ "title": "Keynote: The Universal Cryptographic Adapter",
+ "description": "The \"secret\" third affordance of Zero-Knowledge proof after 1) Privacy and 2) Succinctness is Interoperability. ZK enables us to continuously refactor data, aggregate it from different sources, and transforming it without loosing its integrity.\r\nStarting with the Zupass project, and now with the broader adoption of the POD and GPC format, 0xPARC has been exploring using ZK for data sovereignty and creating more interoperable data ecosystem. We will cover our learnings and progress in this talk.",
+ "track": "Applied Cryptography",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Product",
+ "expertise": "Expert",
+ "audience": "Engineering",
"featured": true,
"doNotRecord": false,
- "tags": [
- "Ethereum Roadmap",
- "Use Cases",
- "macro/micro economics",
- "adoption",
- "africa",
- "mass",
- "Ethereum Roadmap",
- "macro/micro economics",
- "Use Cases"
- ],
"keywords": [
- "Africa",
- "Mass adoption",
- ""
+ "None"
+ ],
+ "tags": [
+ "Not financial",
+ "Permissionless",
+ "ZKP"
],
- "duration": 1531,
"language": "en",
- "sources_swarmHash": "2415d9c9f111fd9ab297194c0cc7b8de5a938accb641bfdb907c2ca01e0958d3",
- "sources_youtubeId": "NtkNYNvuu6w",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733f64b3a168eb53542528d.vtt",
- "transcript_text": " Leonardo Silva Reviewer:\" Elisabeth Buffard Hello everyone. Good to see you all today. I want to start off by asking who is here from the continent of Africa. Can you please raise your hand? Can you guys please stand up? Can you guys please stand up? Let's give this guy a big round of applause because like many of our folks have gone through crazy lengths to get themselves here with visas and everything. And this is the DEF CON that has the largest African builder concentration in one place. And my talk today is around what can we expect over the next 10 years in terms of crypto innovation and is very much inspired by a lot of what I've learned from all these folks and many more of what are the things that have been built today and what can we expect coming up. So two years ago at DEF CON, we established the fact that it's actually the crypto ecosystem that needs Africa to reach its full potential of reaching mass adoption and utility-driven building to scale it to billions of people. And we covered the fact that we are the most populous part of the world and we're growing really fast. That is going to be where all the young people in the world are going to be based at even today we have about 600 million Africans who are the end under the age of 14 that's out of 1.5 billion people and we also discussed around the technology rails that exist that how allowed us to basically skip generations of innovations such as mobile phones skipping landlines or mobile money where that has close to trillion dollars worth of transactions a year and we're jumping traditional banking with crypto. Two years ago when we discussed a lot of this, what was the reality is that mostly many of us were doing crypto to fiat transactions doing payments savings and storing resources or investing using predominantly centralized exchanges and a lot of centralized exchanges are actually not made to be banks they're trading platforms but we kind of figured a way to do that by having various liquidity providers like people like you and I providing liquidity on peer-to-peer their trading platforms. But we kind of figured a way to do that by having various liquidity providers like people like you and I, providing liquidity on peer-to-peer exchanges to drive a lot of the value for normal people to access traditional forms of banking that we need. So where are we today, two years from then? Well, the one reality is that in the traditional world we're still in the same place, that we are communicating value over walls, that the internet, as amazing as it's been at connecting us and letting communication flow, communication of value, which is through monetary systems, are actually very much gated. The internet continues to be very gated. The same way back in the days you would have an operator basically connecting two calls by manually calling the other side and seeing can we trust the other operator. That's the same process that we have today. So we are still working through walls in the traditional system. The other aspect of where we still are today is that a huge part of our economy is happening in the informal sector. That includes our GDP, our prominent GDP is backed by micro enterprises. A huge part of our employment is in the informal economy. A huge part of our GDP is also drive by the informal economy. A huge part of our GDP is also drived by the informal economy and also a lot of our money movement happens outside of the banking system. This is a very important context for us to understand why crypto is thriving so much on the continent. Another big also lens is that we have a systemic US dollar problem. Some of these numbers are a bit outdated but we're importing more than what we're exporting we're taking a lot of debt a lot of african countries debt has doubled in the last 10 years and we're paying that debt plus interest in dollars and we're trading with each other as neighbors using dollars and when our currencies fluctuate so much, then we move our money to dollars. So that creates a demand supply. And on the supply pressure, we have a lot of exports, remittance, people sending money. There's a thing called BRIC. Some of you guys might know about it. Around some countries deciding to settle outside of the dollar system, which is creating a bit less pressure on the dollar. And there's a lot of aid and loans that come in dollars. So what is the consequence of this? Is that basically the US dollars are being rationed by the central banks. The demand for dollars is higher than what they have there. So what you end up having is the bifurcation of the bank rate and the black market rate, or how I call it, the actual market rate um and in worse economies you see that being very large in well-managed economies it's very small but we're living in in parallel systems and also that makes the dollar a commodity so people do unnatural things in order to access dollars because the upside on trading the dollar is higher than the trade on the commodity itself, which creates very weird dysfunctions in our system. And some countries have also created rules of who can own dollars and how much you can transfer it. Until very recently, the Ethiopian government actually made it illegal, meaning you can go to prison for it, for holding more than $500 with you at any given point. Many of my friends' and family's houses were raided, just people looking for dollars. And that's because the central banks don't have enough dollars. And what that means, we borrow more money and then just rinse and repeat. So we have a systemic dollar problem. And so you look at that and say, okay, well, what is crypto doing? Well, fundamentally, what crypto has provided us is basically a digital version of the dollar, US dollar stable coins, that allow for large-scale liquidity coordination mechanism in the informal economy, where a lot of dollars have been circulating physically or through various networks like the Hawala networks that call each other and basically move numbers around. What has that allowed us is basically for early stage startups to be able to aggregate more liquidity than what a bank can in a very short period of time and then settle that payment in a much shorter period of time. And this has been a fundamental value proposition of crypto. So as a result of that, crypto has been thriving, it's been growing. Even in the bear market, crypto transactions have been growing on the continent. Chainalysis says we've had $125 billion worth of transactions last year. When I talk to the analysts and the builders, that's just the tip of the iceberg. There's much more dollars that's been transacted behind that. Nigeria of course is the second most popular place for crypto. And Nigeria, Ethiopia, Kenya, we search crypto online because it is solving fundamental problems for us. But this is not just centralized exchanges. This is happening in other rails that have been built. So actually, some of the builders here in this room have built some of these stacks. These are from the builders in Magma, from wallet infrastructure. So actually making like SDK wallets that you can embed into your fintech application or your crypto application. So you can use crypto and fiat. Aggregating liquidity on-chain and off- off chain which is actually not very easy to do and and simplify the on and off run process through that different types of wallets that are being created and all types of payments from b2b b2c b2b b2c serving like small businesses medium, medium-sized businesses, oil and gas companies, and even banks and payment service providers who are now using these startups to facilitate international payments. And people even issuing debit cards on top of your digital wallet in order to be able to pay online without having any limitations, because some of our banks say, I'm so sorry, you can only pay $10 a month. Well, if you have some resource, you want to buy a book from Amazon, how can you buy it with $10? Amazon is more expensive than that. So you're actually using crypto projects in order to do that. And so some of these projects are way advanced than where I see a lot of on and off ramps. And so, bluntly speaking, if DEF CON was held in one of the countries that were mentioned in Africa, the DEF CON organizing team can pay all their bills using crypto. All of us would basically be using our crypto to make payments with fiat without even needing a fiat wallet paying directly just using the applications that have been built today so there's been a lot of work that has happened in terms of making the user experience a lot easier and if you're curious about it just talk to many of the builders who are in this room so with that in mind what can we expect in the next 10 years what are some of the innovations that we can expect to have? Well, fundamentally, I think the most interesting part of crypto to me is bringing whole economies and powering them by decentralized systems. Part of that is basically changing the foundations of our existing economy, and part of it is like opening up new economic activities that we did not know existed before um and this is where i think ethereum comes in because that's the most robust and the most resilient decentralized system that we have right now so it's it's a beautiful merge here and when we think about rewriting a lot of the foundations of our economies we've got to think about both hyper globalizationglobalization and hyper-localization. We talked a lot about US dollar stablecoins, right? So the answer is not, let's dollarize the entire African economy. Everyone uses dollars, dollars for everyone. That's not the answer. I don't think that helps us and it doesn't help the global economy. So we've got to also think very locally. And one idea I'd love to dive deeper on is this idea of actually local currency stable coins. At the moment, when we think about stable coins, it's kind of synonymous with US dollar stable coins. How about actually having our Kenyan, Nigerian shillings, Nigerian naira, Ethiopian burr, a lot of our local currencies having a digital version of them on-chain. What does that allow? Well, on-chain forex. That makes it a lot more efficient. We'll double-click on that. Cheaper local payments. In a crazy way today, with blobs, it is cheaper to run transactions on a layer 2 at least 5 to 10 times than it is on mobile money or banking, which is quite crazy. Well, that doesn't mean blobs will scale infinitely, but it's just an interesting data point of what we can even do today. And the last part of the value here that we can think of at this stage is that it gives us programmable money, and that opens up a whole lot of opportunities and innovations that can happen. I really want to double click on the on-chain forex. Well today Kenya and Tanzania are neighboring countries right next to each other. We even speak similar languages and both our currencies are called shillings. But in order to make a payment from Kenya to Tanzania you actually have to convert it to the dollar. Dollar has to go through the trade system. It has to flow through London or New York or somewhere. It can take a few days, and depending on the volume, it can take even weeks. It's a very long process and long system. It doesn't make sense that we're having to do this as neighbors, right? With local stablecoins, you could potentially move from the Canadian shilling stablecoin to a Tanzanian shilling stable coin, both denominated in value against the dollar, but not actually touching the dollar. So this helps us move the US dollar from just being a medium of exchange to being a unit of account, which is a very interesting use case for it. So one way that can work is building a pair of liquidity where an importer is putting money into the pool from the Kenyan side and an exporter is pulling money out of it. And the person does the exact same thing on the Tanzanian front. And because every trade does not fully balance, you use dollars to basically rebalance the pool by adding local currency on the other side. This is just one model. I am sure we can come up with way more complex and more interesting models to structure this. But bringing forex on chain is one of the most interesting problems for us to solve using local stable coins. Now, when we think about that, we can think in a few million dollar value, or we can think about half economies. And I think the most important thing that we keep missing in the space when we look at the full potential of crypto is that we're not always looking at how can half an economy run on what we're building, and what needs to be true for us to get there. And the reason why I'm saying that is because, you know, many of you know M-Pesa, right? M-Pesa is one of the best success stories that has come out of Kenya. Half the Kenyan economy runs on M-Pesa. What M-Pesa is, is just a private ledger. It's a spreadsheet where they put some fiat in the bank, and the numbers move from different account names and at the end of the day it's basically settled at the bank layer that's somehow a version of what we're talking about but what we're talking about is putting that on chain and a much more open transparent system right for us to get to that level of scale at a much faster period we've got to think about from different principles and and one lens that I can think of is using government bonds to back our local stable coins. You convert the local bond into a real world asset that can either be fully collateralized through a CDP or a better model that we can come up with. And by the way, if you do, I'd love to chat with you. And basically use that to distribute local currency through existing and new rails around. The forex on-chain is one of the lowest-hanging fruit examples of where we can go, but we can bring so many other values to that. And in the future, it doesn't just need to be government bonds to do this. We can bring other types of assets assets like local land, productive land or protected land or gold and silver and precious metals. We're generating so much of that from Africa at the moment. Or we can do other types of commodities. This is such an open book in terms of what we back our local currencies with. Another pillar after local stablecoins that I love to chat about is simple finance as a stack. Now, here in the Ethereum world, we talk about decentralization a lot. Well, for us on the continent, decentralization is actually a very practical solution to a very practical problem. We have a lot of banking rails to build for hundreds of millions of people, and many of them have not been born yet. To do that, trying to build that in a monolithic way as a centralized company, as one piece, like Alipay or WeChat or Grab for 54 jurisdictions, and scale that in a very short period of time is almost impossible to execute. So the best way for us to do that that in a very short period of time, is almost impossible to execute. So the best way for us to do that, in my view, is just to build a connected web of tools. Different pieces of the Lego that form a financial stack that come together, that offer users a better experience and better options, right? I think building this in a much more decentralized way, to me, is the only way we can get to the level of scale that we need to achieve. So for us, it's actually a very practical solution, a practical way of getting there. And we can build interoperable monies with network effects. Remember the walls, the operator? We can just bypass that and keep moving value across different populations and people in that way. Create cash apps with simple user experience powered by crypto, but we don't even have to know that it's crypto. Today we have startups that are doing that, but we can scale that to infinity. And on the hyper-localization lens, there are many ways we can build around existing trust structures. Across many African countries, we have basically cooperatives and little communities of people. Some of us call them table banking, some of us call them chamas, where basically people pull money together to save and lend to each other. There's a strong trust infrastructure that exists to enable things like that. We don't have to reinvent trust from scratch. We can leverage those existing trust structures to build very resilient, hyper-local economies. And I think that should be part of our roadmap. And beyond, you know, so ultimately, it's just two people or two companies or two agents having normal financial transactions, right? No complexity, not much. We're not talking about crypto at the front end. This is all enabling that. Other areas of innovation that we can think about is like around credentialing, identity, reputation, credit scoring, bringing things that don't exist on chain to create trust on chain are some of the more interesting areas for us to experiment on. We don't have time to dive deep into many of these, and there's a lot more than other areas of innovation that we can build in the next 10 years, but talk to the builders around the table. And the other areas bringing assets on chain, such as real estate. We talked about bonds earlier, but different types of commodities, energy, power generating structures that we need to fund and actually revenue generating. We can experiment with so many of these that actually powers the fundamentals of our economies. So with all these ideas and directions that we can go, you might be wondering, how do I help? How do I connect? How do I participate in this? Well, the first is it's an invitation. It's actually an invitation because there's a lot of building happening on the continent, whether we have a lot of builders coming to DEF CON or not. So it's an invitation for you all from infrastructure, from research, from different ecosystems and chains, from capital allocation, from mentorship and support, from actually working with some of the smartest people on the planet. There are many ways you can plug it into the movement that is happening in Africa. And of course, why not bring DEF CON to Africa in two years' time? Who's down for something like that here? Right? Well, yeah, I think that would be super cool, and you guys will have a blast joining DEF CON there. But it's actually not about having another big event on the continent. It's actually, it gives you a much deeper context to go and see this in practice. It is very, very hard to explain how broken the world gardens are until you actually go and experience it in person. Or it's very hard for me to explain to you like what seamless user experience for crypto looks like without actually going and experiencing and making a whole lot of payments and living your life using your crypto wallet without touching physical bills, right? So it's an invitation for you to actually be part of the movement and work that we have. And lastly, because all the Ethereum events that have happened around the world have happened in places where it's just very hard to get visas, right. So to get 177 folks here, man, that was like a lot of work and it's been a lot of collective effort. And there are hundreds and thousands more that you would absolutely enjoy connecting with and learning with and learning from. And so you're invited home. Welcome, guys. All right. That was an awesome presentation, you guys. We have a Q&A session. So anyone want to put a question, that's the QR right there. Just scan it and put a question there. We have a lot for you, brother. Yes. Let's take a look at which one you want to answer first. We can talk about the non-financial use cases. We can talk about the non-financial use cases. We talked about them later on. Yeah, this talk focused a lot on finance because it's just a lot to unpack. And each topic that we talked around, credentialing, around bringing assets on-chain, and credit scoring, and gaming, and communication, there's a lot to unpack there. I will actually invite you guys to talk to some of our builders here to understand a lot of the nuances. But at the moment, 500 million Africans don't have any form of legal ID. And the best that some of our countries are doing is basically having a data center in one location or two locations and putting the entire population's data there. It's like a honeypot of sovereign data. That's not the most secure way to do it, in my opinion. the entire population's data there. It's like a honeypot of sovereign data, right? That's not the most secure way to do it, in my opinion. So I think there's a lot of ways we can innovate around that. KYC is one that really came up, like transferable KYC across multiple tools. So the list goes on. So the invitation is to actually talk to the builders in the room. Any questions you want to answer? We have a lot more here. All right. What do you see Africa becoming? What do you see Africa becoming a well-coordinated roadmap? I want to talk about regulation. All right, let's go. Because that continues to be a hot topic. And it's really important to us because many of our innovations are interfacing the traditional world with the crypto world because that that door needs to be very fluid it needs to allow money to keep moving back and forth for a long period of time and until we bring it on chain um and i think that's a that's a very important problem so i talked to a bunch of regulators many of the builders here talk to many regulators there's there's curiosity, there's some fear because crypto can be a path for capital flight. A lot of value to live in a short period of time. And that's an actual risk. And some of them don't even understand the fundamentals of this technology. So what we end up having is some countries like South Africa saying, crypto is legal. It's a commodity. We will allow it and so we have a lot of builders working there some countries creating environments for experimentation like sandboxes and actually this is a bit of a controversial view but I think creating some sort of tax revenue from crypto transactions for governments is a potentially positive thing if it's done well, because it moves this category from a risk basis to an income generating category. And bringing local stable coins on chain is, I think, one of the biggest value props for governments, because what it does is it creates a much more efficient capital markets for dollars and bonds it brings dollars in and helps reduce the dollar pressure for local trade that can happen so they have an incentive to see something like that but there's a lot of people here doing the hard work of actually informing regulators and we keep building like we keep building even with gray area we keep building like the show doesn't stop. And I think that's something some of us in, like, the Western world find it hard to kind of navigate around, is because, like, even when Nigeria makes crypto illegal, like, we still have close to 15% of the country's GDP, like, proportion transactions happening in crypto, right? So, yeah, it makes you kind of wonder what some of those kind of guidelines can actually have an effect. I think we have about one or two questions more. Let's see what we want to answer. Am I hiring? Are you hiring? I mean, I don't know, guys. We can jam outside after this and recruit more folks to help answer the question. But yeah, I guess what needs to happen before a DEF CON happens there is there's a lot we've got to do on the continent. We have many communities doing real work. They need a lot of support and engagement. So I think that will bring a lot of value. We need to have more hackathons and builders. But, like, I think our builder community, like, the startups that we have there are, from a user experience perspective, in my opinion, are, like, way ahead from what we keep talking about around usability making crypto usable for daily life like whenever I'm in many African countries like I don't use my card, I don't use cash I'm just like paying all types of bills using my crypto account and I think that's super cool and that's amazing so like even the bill of community alone is enough to host you all. All right. Give a round of applause for the speaker. Thank you.",
+ "speakers": [
+ "justin-glibert"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731407400000,
- "slot_end": 1731409200000,
+ "slot_start": 1731483000000,
+ "slot_end": 1731484800000,
"slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1IAQR41JAk7FPn24OGhprL4uyoP17OlBMG8dv6oyQ_n8",
- "resources_slides": null,
- "speakers": [
- "yoseph-ayele"
- ]
+ "resources_presentation": "https://docs.google.com/presentation/d/1DIuykDDTe3d5hT9NzR3bnBAg1TQAoLS7n9JoGbIFyAg"
},
"vector": [
0,
@@ -454797,11 +453848,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -454972,6 +454023,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -455175,7 +454227,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -455615,6 +454666,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -455622,7 +454674,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -455701,8 +454752,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -455735,7 +454784,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -455756,7 +454804,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -455780,6 +454827,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -455807,6 +454855,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -455941,7 +454990,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -456104,15 +455152,15 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -456126,47 +455174,46 @@
},
{
"session": {
- "id": "keynote-the-real-state-of-l2s",
- "sourceId": "HCXUU8",
- "title": "Keynote: The REAL state of L2s",
- "description": "The evolution of Layer 2 solutions has been pivotal in scaling blockchain technologies. This talk, led by L2BEAT founder Bartek Kiepuszewski, delves into the current landscape, recent advancements, and future potential of L2 ecosystems. It will try to address some myths and current challenges of the space. Some important changes to L2BEAT risk framework will also be announced.",
- "track": "Layer 2",
+ "id": "keynote-title-redacted",
+ "sourceId": "8GH8TR",
+ "title": "Keynote: [title redacted]",
+ "description": "[description redacted]",
+ "track": "Core Protocol",
"type": "Talk",
"expertise": "Intermediate",
"audience": "Community",
"featured": true,
"doNotRecord": false,
"tags": [
- "Architecture",
- "Layer 2s",
- "Best Practices",
- "myths",
- "reality",
- "Architecture",
- "Best Practices",
- "Layer 2s"
+ "Consensus",
+ "Ethereum Roadmap",
+ "cryptoeconomy",
+ "Consensus",
+ "Core Protocol",
+ "Ethereum Roadmap"
],
"keywords": [
- "L2Risks",
- "Myths&Reality"
+ "beacon chain",
+ "research",
+ "cryptoeconomics"
],
- "duration": 1530,
+ "duration": 1553,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "GJ1L2dBkrWE",
+ "sources_swarmHash": "93e32548a38d598d71fdd21d2c49f3012ba3a510cc1214362a4ebbda8529763e",
+ "sources_youtubeId": "Plvy7fgFCm4",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
"transcript_vtt": "No VTT link provided",
"transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731472200000,
- "slot_end": 1731474000000,
+ "slot_start": 1731405600000,
+ "slot_end": 1731407400000,
"slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1NxPv65UP8MJMX2f8NWmiAL-GETRNifiDtkZS5evBvV0",
+ "resources_presentation": "https://docs.google.com/presentation/d/1hcsmjIHu5W9-usVg_e3DGrH4QnmLER-OPOZ_0ccXjKU",
"resources_slides": null,
"speakers": [
- "bartek-kiepuszewski"
+ "justin-drake"
]
},
"vector": [
@@ -456174,10 +455221,10 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -456924,6 +455971,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -456937,6 +455985,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -456953,9 +456002,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -456984,11 +456030,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -457114,6 +456158,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -457167,7 +456212,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -457505,33 +456549,48 @@
},
{
"session": {
- "id": "keynote-the-universal-cryptographic-adapter",
- "sourceId": "R9X9ZG",
- "title": "Keynote: The Universal Cryptographic Adapter",
- "description": "The \"secret\" third affordance of Zero-Knowledge proof after 1) Privacy and 2) Succinctness is Interoperability. ZK enables us to continuously refactor data, aggregate it from different sources, and transforming it without loosing its integrity.\r\nStarting with the Zupass project, and now with the broader adoption of the POD and GPC format, 0xPARC has been exploring using ZK for data sovereignty and creating more interoperable data ecosystem. We will cover our learnings and progress in this talk.",
- "track": "Applied Cryptography",
+ "id": "keynote-unifying-ethereum-through-intents-and-erc-7683",
+ "sourceId": "WHYZCD",
+ "title": "Keynote: Unifying Ethereum Through Intents and ERC-7683",
+ "description": "Ethereum has scaled with a diverse ecosystem of L2s—but this created a new challenge: how can this fragmented landscape of potentially millions of rollups feel like a **unified Ethereum**? In this talk, I’ll discuss how intent-based architectures—and new standards like ERC-7683—can help unify Ethereum while maintaining the benefits of Ethereum’s rollup centric architecture.",
+ "track": "Layer 2",
"type": "Talk",
- "expertise": "Expert",
- "audience": "Engineering",
+ "expertise": "Intermediate",
+ "audience": "Product",
"featured": true,
"doNotRecord": false,
- "keywords": [
- "None"
- ],
"tags": [
- "Not financial",
- "Permissionless",
- "ZKP"
+ "Cross-L2",
+ "UI/UX",
+ "Intents",
+ "interoperability",
+ "erc-7683",
+ "Cross-L2",
+ "Intents",
+ "UI/UX"
],
- "language": "en",
- "speakers": [
- "justin-glibert"
+ "keywords": [
+ "ERC-7683",
+ "Interoperability"
],
+ "duration": 1543,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "6ixvMwGb1oY",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67345cf19dbb7a90e14fb5ef.vtt",
+ "transcript_text": " So my talk here following up on that panel, an amazing panel, and let's give a thank you to Vitalik, to yeah, I think Vitalik, but also Ben, Jesse, Steven. Um, it was an awesome talk. So, uh, we're gonna talk, continue the conversation about how we unify Ethereum, uh, with Intents and ERC 7683. Um, and so I'm Hart. I am the, uh, co-founder of Across Protocol. Uh, we are an intent-based interoperability and bridging protocol. Um, but we're gonna talk about the standard and how we developed it and how we built support for it, which we talked about on that panel too. Okay. So I stole some of the slides from my intro to the panel because they were so good I needed to use them. But I'm going to replay quickly some of the slides just to set the framework for what we're talking about here. So four years ago, Ethereum had the scaling problem. We had 15 transactions per second. At peak demand, Ethereum was so expensive, it was basically unusable. And Vitalik helped us align the Ethereum community around this roll-up-centric roadmap. And this worked. I walked through these slides on the panel we were just on. But look at what we did here. In October 2020, we aligned on the roll-up-centric roadmap. Optimism shipped a couple months later. Arbitrum shipped a couple months after that. ZK Sync shipped a year after that with ZK rollups. We had this like massive innovation in this rollup-centric architecture. And then of course, Blobs came around just this year. So March of this year. And I don't know if you guys just saw the charts or I honestly should have included another chart in here. The cost of transactions on Ethereum just plummeted. And now on an L2, you can do a transaction for pennies. We actually saw this in a crosses data. The median transaction size dropped from about 500 bucks going L2 to L2 when you're bridging is now 50 bucks and we have real consumer use cases because these these L2s",
"eventId": "devcon-7",
"slot_start": 1731483000000,
"slot_end": 1731484800000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1DIuykDDTe3d5hT9NzR3bnBAg1TQAoLS7n9JoGbIFyAg"
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1HFUKCdHq2CnGEM-2BvyaHipzeUf2aeP32TKRHPxKnWY",
+ "resources_slides": null,
+ "speakers": [
+ "hart-lambur"
+ ]
},
"vector": [
0,
@@ -457541,9 +456600,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -457716,27 +456772,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -457991,6 +457026,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -458365,6 +457401,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -458478,6 +457515,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -458504,6 +457542,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -458523,11 +457562,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -458551,7 +457585,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -458700,6 +457733,26 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -458850,7 +457903,6 @@
0,
0,
0,
- 2,
2,
0,
0,
@@ -458859,6 +457911,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -458869,56 +457925,41 @@
},
{
"session": {
- "id": "keynote-title-redacted",
- "sourceId": "8GH8TR",
- "title": "Keynote: [title redacted]",
- "description": "[description redacted]",
- "track": "Core Protocol",
+ "id": "keynote-world-politics-world-building",
+ "sourceId": "ERQKUX",
+ "title": "Keynote: World Politics, World Building",
+ "description": "World politics has changed. Geopolitics is no longer simply a contest to control territory: in this age of advanced technology, it has become a contest to create the territory. Great powers seek to build a world for other states to inhabit, while keeping the ability to change the rules or the state of the world when necessary. At a moment when the old concepts no longer work, this book aims to introduce a radically new theory of world politics and technology. The end goal: god mode",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Community",
+ "expertise": "Beginner",
+ "audience": "Academic",
"featured": true,
"doNotRecord": false,
- "tags": [
- "Consensus",
- "Ethereum Roadmap",
- "cryptoeconomy",
- "Consensus",
- "Core Protocol",
- "Ethereum Roadmap"
- ],
"keywords": [
- "beacon chain",
- "research",
- "cryptoeconomics"
+ "World Building",
+ "Technology",
+ "Geopolitics"
],
- "duration": 1553,
+ "tags": [],
"language": "en",
- "sources_swarmHash": "93e32548a38d598d71fdd21d2c49f3012ba3a510cc1214362a4ebbda8529763e",
- "sources_youtubeId": "Plvy7fgFCm4",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731405600000,
- "slot_end": 1731407400000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1hcsmjIHu5W9-usVg_e3DGrH4QnmLER-OPOZ_0ccXjKU",
- "resources_slides": null,
"speakers": [
- "justin-drake"
- ]
+ "bruno-macaes"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731652200000,
+ "slot_end": 1731654000000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/171MvUF1M-7FvPkuWLfzY3WGZzA0pW2lZXE-foWeOt4Q"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -459669,7 +458710,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -459683,7 +458723,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -459856,7 +458895,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -460064,7 +459102,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -460225,20 +459262,20 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -460247,48 +459284,39 @@
},
{
"session": {
- "id": "keynote-unifying-ethereum-through-intents-and-erc-7683",
- "sourceId": "WHYZCD",
- "title": "Keynote: Unifying Ethereum Through Intents and ERC-7683",
- "description": "Ethereum has scaled with a diverse ecosystem of L2s—but this created a new challenge: how can this fragmented landscape of potentially millions of rollups feel like a **unified Ethereum**? In this talk, I’ll discuss how intent-based architectures—and new standards like ERC-7683—can help unify Ethereum while maintaining the benefits of Ethereum’s rollup centric architecture.",
- "track": "Layer 2",
- "type": "Talk",
+ "id": "kickstarting-impact-funding-with-hypercerts",
+ "sourceId": "VGZ7PP",
+ "title": "Kickstarting impact funding with hypercerts",
+ "description": "Create hypercerts, evaluate their content and fund what matters by building on top of the hypercerts ecosystem. Building on top of a decentralised registry of impactful work, the hypercerts ecosystem empowers impact creators to explore novel forms of impact funding and resource coordination. \r\n\r\nDuring this workshop we'll explore the hypercerts stack and help you mint, evaluate and trade your first on-chain impact certificates.",
+ "track": "Real World Ethereum",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Product",
- "featured": true,
+ "audience": "Engineering",
+ "featured": false,
"doNotRecord": false,
- "tags": [
- "Cross-L2",
- "UI/UX",
- "Intents",
- "interoperability",
- "erc-7683",
- "Cross-L2",
- "Intents",
- "UI/UX"
- ],
"keywords": [
- "ERC-7683",
- "Interoperability"
+ "Impact",
+ "Funding"
+ ],
+ "tags": [
+ "DevEx",
+ "RPGF",
+ "Best Practices",
+ "funding",
+ "Best Practices",
+ "DevEx",
+ "RPGF"
],
- "duration": 1543,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "6ixvMwGb1oY",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67345cf19dbb7a90e14fb5ef.vtt",
- "transcript_text": " So my talk here following up on that panel, an amazing panel, and let's give a thank you to Vitalik, to yeah, I think Vitalik, but also Ben, Jesse, Steven. Um, it was an awesome talk. So, uh, we're gonna talk, continue the conversation about how we unify Ethereum, uh, with Intents and ERC 7683. Um, and so I'm Hart. I am the, uh, co-founder of Across Protocol. Uh, we are an intent-based interoperability and bridging protocol. Um, but we're gonna talk about the standard and how we developed it and how we built support for it, which we talked about on that panel too. Okay. So I stole some of the slides from my intro to the panel because they were so good I needed to use them. But I'm going to replay quickly some of the slides just to set the framework for what we're talking about here. So four years ago, Ethereum had the scaling problem. We had 15 transactions per second. At peak demand, Ethereum was so expensive, it was basically unusable. And Vitalik helped us align the Ethereum community around this roll-up-centric roadmap. And this worked. I walked through these slides on the panel we were just on. But look at what we did here. In October 2020, we aligned on the roll-up-centric roadmap. Optimism shipped a couple months later. Arbitrum shipped a couple months after that. ZK Sync shipped a year after that with ZK rollups. We had this like massive innovation in this rollup-centric architecture. And then of course, Blobs came around just this year. So March of this year. And I don't know if you guys just saw the charts or I honestly should have included another chart in here. The cost of transactions on Ethereum just plummeted. And now on an L2, you can do a transaction for pennies. We actually saw this in a crosses data. The median transaction size dropped from about 500 bucks going L2 to L2 when you're bridging is now 50 bucks and we have real consumer use cases because these these L2s",
- "eventId": "devcon-7",
- "slot_start": 1731483000000,
- "slot_end": 1731484800000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1HFUKCdHq2CnGEM-2BvyaHipzeUf2aeP32TKRHPxKnWY",
- "resources_slides": null,
"speakers": [
- "hart-lambur"
- ]
+ "holke-brammer",
+ "bitbeckers"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731576600000,
+ "slot_end": 1731582000000,
+ "slot_roomId": "classroom-c",
+ "resources_presentation": "https://docs.google.com/presentation/d/1-2n2zwPdIpfxkXDYIJI5vN-Bz4JCM93vP20YXjSCQ4I"
},
"vector": [
0,
@@ -460297,7 +459325,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -460725,11 +459752,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -461072,6 +460098,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -461098,11 +460126,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -461216,7 +460242,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -461243,7 +460268,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -461310,6 +460334,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -461356,6 +460381,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -461435,7 +460461,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -461608,11 +460633,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -461626,31 +460651,25 @@
},
{
"session": {
- "id": "keynote-world-politics-world-building",
- "sourceId": "ERQKUX",
- "title": "Keynote: World Politics, World Building",
- "description": "World politics has changed. Geopolitics is no longer simply a contest to control territory: in this age of advanced technology, it has become a contest to create the territory. Great powers seek to build a world for other states to inhabit, while keeping the ability to change the rules or the state of the world when necessary. At a moment when the old concepts no longer work, this book aims to introduce a radically new theory of world politics and technology. The end goal: god mode",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Academic",
- "featured": true,
+ "id": "ktv-attestation-winners",
+ "sourceId": "MP9UQV",
+ "title": "KTV Attestation Winners",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
+ "featured": false,
"doNotRecord": false,
- "keywords": [
- "World Building",
- "Technology",
- "Geopolitics"
- ],
+ "keywords": [],
"tags": [],
"language": "en",
- "speakers": [
- "bruno-macaes"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731652200000,
- "slot_end": 1731654000000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/171MvUF1M-7FvPkuWLfzY3WGZzA0pW2lZXE-foWeOt4Q"
+ "slot_start": 1731486600000,
+ "slot_end": 1731488400000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1r7I3zIxHezXZS2fH5PPvuIsIk0QSyDWrsnAqeEl-U6o"
},
"vector": [
0,
@@ -461659,11 +460678,10 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -462088,7 +461106,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -462966,6 +461983,7 @@
0,
0,
0,
+ 2,
0,
0,
2,
@@ -462979,8 +461997,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0
@@ -462988,39 +462004,25 @@
},
{
"session": {
- "id": "kickstarting-impact-funding-with-hypercerts",
- "sourceId": "VGZ7PP",
- "title": "Kickstarting impact funding with hypercerts",
- "description": "Create hypercerts, evaluate their content and fund what matters by building on top of the hypercerts ecosystem. Building on top of a decentralised registry of impactful work, the hypercerts ecosystem empowers impact creators to explore novel forms of impact funding and resource coordination. \r\n\r\nDuring this workshop we'll explore the hypercerts stack and help you mint, evaluate and trade your first on-chain impact certificates.",
- "track": "Real World Ethereum",
- "type": "Workshop",
- "expertise": "Intermediate",
+ "id": "ktv-winners",
+ "sourceId": "UYQFMA",
+ "title": "KTV Winners",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Impact",
- "Funding"
- ],
- "tags": [
- "DevEx",
- "RPGF",
- "Best Practices",
- "funding",
- "Best Practices",
- "DevEx",
- "RPGF"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "holke-brammer",
- "bitbeckers"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731576600000,
- "slot_end": 1731582000000,
- "slot_roomId": "classroom-c",
- "resources_presentation": "https://docs.google.com/presentation/d/1-2n2zwPdIpfxkXDYIJI5vN-Bz4JCM93vP20YXjSCQ4I"
+ "slot_start": 1731501000000,
+ "slot_end": 1731501900000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1cuZ-hN8gOGCEQohCTOeJVPCVT4HAWbG9sWbvDGpwg_Y"
},
"vector": [
0,
@@ -463029,10 +462031,10 @@
0,
0,
0,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -463459,8 +462461,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -463805,8 +462805,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -464042,7 +463040,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -464089,7 +463086,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -464336,10 +463332,13 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 0,
+ 2,
+ 0,
+ 0,
2,
0,
0,
@@ -464358,25 +463357,45 @@
},
{
"session": {
- "id": "ktv-attestation-winners",
- "sourceId": "MP9UQV",
- "title": "KTV Attestation Winners",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
+ "id": "l1sload-in-action-write-l2-dapps-that-read-from-l1-state",
+ "sourceId": "ERQ7N3",
+ "title": "L1SLOAD in Action: Write L2 Dapps that Read from L1 State",
+ "description": "In this workshop we will explore some interesting new use cases unlocked by the newly proposed L1SLOAD precompile (RIP-7728). We will develop and deploy L2 dapps that read from L1 state using this precompile.",
+ "track": "Layer 2",
+ "type": "Workshop",
+ "expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "tags": [
+ "Developer Infrastructure",
+ "DevEx",
+ "Rollups"
+ ],
+ "keywords": [
+ "RIP",
+ "L1SLOAD",
+ "Precompile"
+ ],
+ "duration": 5064,
"language": "en",
- "speakers": [],
+ "sources_swarmHash": "4eb65f6c60b1496a7551b229ed23560c241cd3229d0222453f48e4d1c7d143fc",
+ "sources_youtubeId": "R9-QpN-hr6w",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731486600000,
- "slot_end": 1731488400000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1r7I3zIxHezXZS2fH5PPvuIsIk0QSyDWrsnAqeEl-U6o"
+ "slot_start": 1731394800000,
+ "slot_end": 1731400200000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/1bocSfX9_K930B6knXp5J9HUDPwUP0hIP5UeWRegKZ_E",
+ "resources_slides": null,
+ "speakers": [
+ "peter-garamvolgyi",
+ "rh"
+ ]
},
"vector": [
0,
@@ -464386,8 +463405,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -464818,6 +463835,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -465158,6 +464177,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -465169,6 +464189,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -465180,11 +464201,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -465695,7 +464712,6 @@
0,
2,
0,
- 0,
2,
0,
0,
@@ -465714,25 +464730,39 @@
},
{
"session": {
- "id": "ktv-winners",
- "sourceId": "UYQFMA",
- "title": "KTV Winners",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
+ "id": "l1sload-precompile-read-l1-state-from-your-l2-contract",
+ "sourceId": "VRXWFH",
+ "title": "L1SLOAD Precompile: Read L1 State from your L2 Contract",
+ "description": "We recently introduced [RIP 7728: L1SLOAD Precompile](https://github.com/ethereum/RIPs/pull/27). This is a new L2 precompile that allows dapps on L2s to read from the L1 state.\r\n\r\nIn this talk, we will explain how L1SLOAD works, and we will highlight some of the most exciting use cases that this precompile will unlock.",
+ "track": "Layer 2",
+ "type": "Talk",
+ "expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "RIPs",
+ "L1SLOAD",
+ "Precompile"
+ ],
+ "tags": [
+ "Cross-L2",
+ "Developer Infrastructure",
+ "DevEx",
+ "precompile",
+ "Cross-L2",
+ "Developer Infrastructure",
+ "DevEx"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "peter-garamvolgyi"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731501000000,
- "slot_end": 1731501900000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1cuZ-hN8gOGCEQohCTOeJVPCVT4HAWbG9sWbvDGpwg_Y"
+ "slot_start": 1731581400000,
+ "slot_end": 1731582600000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1nkzZ5Gin2GWcgGhvYhOmVQywSYCjYFlNu3xeFIu8YLs"
},
"vector": [
0,
@@ -465742,8 +464772,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -466174,6 +465202,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -466515,6 +465544,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -466538,6 +465568,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -466683,6 +465714,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -466882,11 +465914,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -467051,7 +466079,6 @@
0,
2,
0,
- 0,
2,
0,
0,
@@ -467070,45 +466097,38 @@
},
{
"session": {
- "id": "l1sload-in-action-write-l2-dapps-that-read-from-l1-state",
- "sourceId": "ERQ7N3",
- "title": "L1SLOAD in Action: Write L2 Dapps that Read from L1 State",
- "description": "In this workshop we will explore some interesting new use cases unlocked by the newly proposed L1SLOAD precompile (RIP-7728). We will develop and deploy L2 dapps that read from L1 state using this precompile.",
- "track": "Layer 2",
- "type": "Workshop",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "id": "l2-daos-biggest-challenges-we-face-to-make-l2s-sustainable-long-term",
+ "sourceId": "BF8EWR",
+ "title": "L2 DAOs - biggest challenges we face to make L2s sustainable long term",
+ "description": "Today L2 DAOs are mostly focused on growth and supporting their ecosystem builders. But long-term they will be responsible for the management and maintenance of their chains from all perspectives - ecosystem growth, software development, security, chain economic parameters management, and others. In this talk, I will explore what DAOs need to figure out and fix before they will be able to take this responsibility in the coming years and why we should be addressing those issues already today.",
+ "track": "Coordination",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Developer Infrastructure",
- "DevEx",
- "Rollups"
- ],
"keywords": [
- "RIP",
- "L1SLOAD",
- "Precompile"
+ "structures",
+ "processes"
+ ],
+ "tags": [
+ "Coordination",
+ "DAO",
+ "Governance",
+ "processes",
+ "Coordination",
+ "DAO",
+ "Governance"
],
- "duration": 5064,
"language": "en",
- "sources_swarmHash": "4eb65f6c60b1496a7551b229ed23560c241cd3229d0222453f48e4d1c7d143fc",
- "sources_youtubeId": "R9-QpN-hr6w",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731394800000,
- "slot_end": 1731400200000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/1bocSfX9_K930B6knXp5J9HUDPwUP0hIP5UeWRegKZ_E",
- "resources_slides": null,
"speakers": [
- "peter-garamvolgyi",
- "rh"
- ]
+ "krzysztof-urbanski"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731638700000,
+ "slot_end": 1731640500000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1vQuKk5kYywWP8c4RZ3Xv_lV6TMmiWy4s6jRMdeFV9MU"
},
"vector": [
0,
@@ -467118,14 +466138,11 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -467549,12 +466566,11 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -467893,7 +466909,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -467905,7 +466920,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -467917,7 +466931,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -467963,10 +466976,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -468020,6 +467035,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -468152,6 +467168,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -468424,16 +467441,16 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -468446,39 +467463,30 @@
},
{
"session": {
- "id": "l1sload-precompile-read-l1-state-from-your-l2-contract",
- "sourceId": "VRXWFH",
- "title": "L1SLOAD Precompile: Read L1 State from your L2 Contract",
- "description": "We recently introduced [RIP 7728: L1SLOAD Precompile](https://github.com/ethereum/RIPs/pull/27). This is a new L2 precompile that allows dapps on L2s to read from the L1 state.\r\n\r\nIn this talk, we will explain how L1SLOAD works, and we will highlight some of the most exciting use cases that this precompile will unlock.",
+ "id": "l2-evm-common-core-a-path-beyond-evm-equivalence",
+ "sourceId": "9RJ3MA",
+ "title": "L2 EVM Common Core: A Path Beyond EVM Equivalence",
+ "description": "Network effects of the EVM have locked many of the L2s into equivalence with the L1 EVM. L1 is optimized for moderate throughput and maximal decentralization, but L2s need higher throughput and can rely on heavier full nodes.\r\n\r\nThe talk will present a vision for an L2 EVM Common Core as a new base VM for participating L2s. It aims to offer a way to ship more ambitious EVM changes without increasing L2 fragmentation. It is a result of our work as leads of the RollCall L2 coordination process.",
"track": "Layer 2",
"type": "Talk",
- "expertise": "Beginner",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "RIPs",
- "L1SLOAD",
- "Precompile"
- ],
+ "keywords": [],
"tags": [
- "Cross-L2",
- "Developer Infrastructure",
- "DevEx",
- "precompile",
- "Cross-L2",
- "Developer Infrastructure",
- "DevEx"
+ "EVM-equivalent",
+ "Rollups"
],
"language": "en",
"speakers": [
- "peter-garamvolgyi"
+ "ansgar-dietrichs"
],
"eventId": "devcon-7",
- "slot_start": 1731581400000,
+ "slot_start": 1731580800000,
"slot_end": 1731582600000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1nkzZ5Gin2GWcgGhvYhOmVQywSYCjYFlNu3xeFIu8YLs"
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/12XdvKPNbvuPDHnrej4p-WzreCiZV7ATA5gFRxh1Vejk"
},
"vector": [
0,
@@ -468538,6 +467546,16 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -468919,7 +467937,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -469287,7 +468304,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -469433,7 +468449,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -469546,6 +468561,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -469634,24 +468657,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -469794,9 +468799,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
2,
0,
@@ -469816,38 +468821,37 @@
},
{
"session": {
- "id": "l2-daos-biggest-challenges-we-face-to-make-l2s-sustainable-long-term",
- "sourceId": "BF8EWR",
- "title": "L2 DAOs - biggest challenges we face to make L2s sustainable long term",
- "description": "Today L2 DAOs are mostly focused on growth and supporting their ecosystem builders. But long-term they will be responsible for the management and maintenance of their chains from all perspectives - ecosystem growth, software development, security, chain economic parameters management, and others. In this talk, I will explore what DAOs need to figure out and fix before they will be able to take this responsibility in the coming years and why we should be addressing those issues already today.",
- "track": "Coordination",
+ "id": "l2-interoperability-via-collaborative-snarks",
+ "sourceId": "JPGEPU",
+ "title": "L2 Interoperability via Collaborative SNARKs",
+ "description": "Can contracts across rollups interact synchronously while maintaining horizontal scalability? The L2 interoperability problem can be viewed through the lens of collaborative SNARKs, where a coordinator splits a witness over N provers who collectively generate a proof, and the work each prover does should decrease linearly in N (horizonal scaling). This talk presents a solution for the special case of L2 interoperability and motivates new design constraints for SNARKs.",
+ "track": "Layer 2",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "structures",
- "processes"
+ "Interoperability"
],
"tags": [
- "Coordination",
- "DAO",
- "Governance",
- "processes",
- "Coordination",
- "DAO",
- "Governance"
+ "Fragmentation",
+ "Zk Rollups",
+ "Cryptography",
+ "interoperability",
+ "Cryptography",
+ "Fragmentation",
+ "Zk Rollups"
],
"language": "en",
"speakers": [
- "krzysztof-urbanski"
+ "ben-fisch"
],
"eventId": "devcon-7",
- "slot_start": 1731638700000,
- "slot_end": 1731640500000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1vQuKk5kYywWP8c4RZ3Xv_lV6TMmiWy4s6jRMdeFV9MU"
+ "slot_start": 1731474000000,
+ "slot_end": 1731475800000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ZVK2vJYrK2rxz9r6LEc4JhYeEu_tVk_8Q4kLDWRxY9k"
},
"vector": [
0,
@@ -469857,11 +468861,11 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -470612,6 +469616,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -470641,6 +469646,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -470666,6 +469672,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -470698,12 +469705,7 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
- 2,
0,
0,
0,
@@ -470757,7 +469759,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -470891,7 +469892,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -470994,6 +469994,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -471168,11 +470169,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -471185,30 +470186,37 @@
},
{
"session": {
- "id": "l2-evm-common-core-a-path-beyond-evm-equivalence",
- "sourceId": "9RJ3MA",
- "title": "L2 EVM Common Core: A Path Beyond EVM Equivalence",
- "description": "Network effects of the EVM have locked many of the L2s into equivalence with the L1 EVM. L1 is optimized for moderate throughput and maximal decentralization, but L2s need higher throughput and can rely on heavier full nodes.\r\n\r\nThe talk will present a vision for an L2 EVM Common Core as a new base VM for participating L2s. It aims to offer a way to ship more ambitious EVM changes without increasing L2 fragmentation. It is a result of our work as leads of the RollCall L2 coordination process.",
+ "id": "l2-specific-mev-mitigation-strategies",
+ "sourceId": "FFWJAV",
+ "title": "L2 Specific MEV Mitigation Strategies",
+ "description": "MEV mitigation and prevention has primarily been researched in the base L1 Ethereum layer. This talk explores L2 specific strategies, including the future in the event of decentralized sequencing. We explore emerging EIP proposals and drafts (EIP-7640), the use of intents in L2s and other new constructions.",
"track": "Layer 2",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
+ "keywords": [
+ "DeFi"
+ ],
"tags": [
- "EVM-equivalent",
+ "Layer 2s",
+ "Rollups",
+ "MEV",
+ "defi",
+ "Layer 2s",
+ "MEV",
"Rollups"
],
"language": "en",
"speakers": [
- "ansgar-dietrichs"
+ "joseph-poon"
],
"eventId": "devcon-7",
- "slot_start": 1731580800000,
- "slot_end": 1731582600000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/12XdvKPNbvuPDHnrej4p-WzreCiZV7ATA5gFRxh1Vejk"
+ "slot_start": 1731646800000,
+ "slot_end": 1731648600000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1WzPEAvLhXYIe49IEB4HEC3EgI2OglZ-ElusjYDJG2QY"
},
"vector": [
0,
@@ -471268,11 +470276,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -471657,6 +470660,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -471966,6 +470970,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -472029,6 +471034,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -472153,6 +471159,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -472287,8 +471294,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -472528,8 +471533,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -472546,44 +471551,54 @@
},
{
"session": {
- "id": "l2-interoperability-via-collaborative-snarks",
- "sourceId": "JPGEPU",
- "title": "L2 Interoperability via Collaborative SNARKs",
- "description": "Can contracts across rollups interact synchronously while maintaining horizontal scalability? The L2 interoperability problem can be viewed through the lens of collaborative SNARKs, where a coordinator splits a witness over N provers who collectively generate a proof, and the work each prover does should decrease linearly in N (horizonal scaling). This talk presents a solution for the special case of L2 interoperability and motivates new design constraints for SNARKs.",
- "track": "Layer 2",
- "type": "Talk",
+ "id": "latency-advantage-in-cex-dex-arbitrage",
+ "sourceId": "RPMHLF",
+ "title": "Latency Advantage in CEX-DEX Arbitrage",
+ "description": "We study the effects of having latency advantage in the CEX-DEX arbitrage in the first-come first-serve transaction ordering policies. We search for optimal strategies for a trader that owns such advantage. To find optimal strategies, we simulate price changes on CEX using real data and assume DEX price does not change in the latency advantage interval. We find that optimal strategy can even be to trade right away as soon as the price difference crosses a threshold where trading is profitable",
+ "track": "Cryptoeconomics",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Interoperability"
- ],
"tags": [
- "Fragmentation",
- "Zk Rollups",
- "Cryptography",
- "interoperability",
- "Cryptography",
- "Fragmentation",
- "Zk Rollups"
+ "Rollups",
+ "Economics",
+ "MEV",
+ "AMMs",
+ "programming",
+ "dynamic",
+ "AMMs",
+ "Economics",
+ "MEV",
+ "Rollups"
],
- "language": "en",
- "speakers": [
- "ben-fisch"
+ "keywords": [
+ "Optimal",
+ "Stopping;",
+ "Dynamic",
+ "Programming;"
],
+ "duration": 562,
+ "language": "en",
+ "sources_swarmHash": "373cd46037e49db5d6daf67c74b2a86e58ffe6dbe5747c1938a919384ce69f95",
+ "sources_youtubeId": "9r7hmxQ8DTA",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673468a09dbb7a90e188a277.vtt",
+ "transcript_text": " . Hello everyone. Welcome to the presentation. Today, I will talk about MEV capture through time advantage arbitrage. So this is the title of the paper that we wrote together with Ed Felten, Robin Frisch, Maria Silva, and Benjamin Lifshitz. This is different from the title of the session. So take your time to take a picture or write it down. It will be gone. I cannot go really back. So initially, I submitted it as a 20-minute presentation, but it was demoted to five minutes. So the only thing I can do is to motivate you to read the paper. And I hope I can do that. Okay, so main part, motivation. So we tried to understand what TimeBoost does to MEV, and to give you a very quick introduction in the TimeBoost, this is selling Fastlane license that allows one player to have 200 millisecond advantage over all other players and this advantage lasts only for one minute and after one minute there will be another auction. Then advantages of course achieved by delaying all the other transactions by other users. And we want to understand the arbitrage between automated market makers and outside markets. So we have a lot of assumptions in order to derive our few theoretical results and many simulation results. So we assume that in the outside markets fees are very low or let's say zero, and the price discovery happens on the external market. On the IMM that is on the chain, it's only arbitrage transactions. Of course, there are some noise transactions as well, but we assume that they can go into both directions, so they cancel the effects. We also assume the efficient market assumption which is that the price depends only on the current, so price change doesn't depend on the previous price changes, so it's a pure random process which is of course not true in reality and we even observed on the data that it's not true. So the model looks like this, We have this one player that has this time advantage during time t. There are two assets, one risky asset and the numeraire. Think of as Ether risky asset and numeraire USD or the other way around. The AMM has a trading fee and the risky assets price changes on the outside market. So initially we assume initially of the simulation we assume that they are the same, the prices are the same, and then once the arbitrage opportunity arises on the outside market, so price moves, then arbitrage needs to decide when to capitalize on it. And we assume that it has only time advantage time so after this time passes opportunity will be taken away by other arbitrage and this is a conservative assumption for the arbitrage value so this reduces to an optimization problem so So we have time advantage arbitrage here, and we have three parameters that give a state. What is the current price difference, relative time, so price difference? How much time passed in this 200 millisecond? And how much time passed in the total period time? And we need to decide between trading, so taking the arbitrage, or waiting. And the punchline here is that dynamic programming solves this problem. And with dynamic programming, we simulate it on the real data. So we took, let's say, Ethereum USDT market on the Binance, and we step size 10 millisecond. We have advantage window 200 millisecond and total time one minute. And we can calculate for each point, internal point. We can calculate what is the optimal move and also what is the average gains, average arbitrage value. And we obtained the observation that waiting till the end of this advantage time is mostly optimal, but not always. So there are some cases when it's not optimal. So I will not give you any numbers, because that's the only thing that people remember in the end, how much money time boost makes with these assumptions. But it gives some upper bound on this type of arbitrage, so decentralized exchange arbitrage. Additionally to this, we also looked into opportunity to let the pool contract know about time boosted transactions which allows them to price such transactions differently and this introduces some interesting game between LPS and the time advantage the arbitrage and then we can calculate what will be the distribution of value between these two and other arbitrage years so thank you for your attention happy to answer questions about this and the time boost in general. Thank you very much. So raise your hand if you have any questions. Yep, over there. There first. Oops, sorry. Sorry. Thanks. Do you think it's a good idea to use one minute allocation for arbitrage? Is this too long? Have you tried to do shorter simulation times? I ask for, because MEV, multi-block MEV has been a problem. We don't understand it very well. So have you tried to simulate shorter? So we, in simulation, of course, you can simulate and get results, what you get. But we thought that one minute is not very long, because if you make it longer, it's even worse from your perspective. But if you make it shorter, we need to conduct this auction too frequently. And that also has some cost. So that was this kind of trade-off that we analyzed. There's another question over there. Did you try this using real money, and did you find anything interesting between real and simulation? So we didn't try real money, but you are welcome to try. We analyzed the backtesting, so this data was taken in July. But in principle, you can forward test that too once once it's there but you can also forward without time post deployed on arbitrum you can just assume that you have this advantage and you can then see how much you can make with the strategies that we suggest so answer is it's very easy to do, but we didn't do it. Hi, this is Kenneth, and I'm not sure if you covered it, but was any differential gas price that was taken into consideration in your simulation? So what differential I didn't get? Gas. Amount gas fees. Or decentralized exchange. Decentralization. Yeah. The gas fees. Ah. So gas fees we assume to be, let's say, sub-cent for the exchange. So we took realistic gas fees and subtracted from the gains. But they are very not substantial for the results. I see. Thank you. There's one last question over there. Oh, over there? Okay. Over there, yeah. Yeah. What kind of inventory is needed to actually pull this off in a relatively profitable manner? I mean, you need to have both assets on the chain and on the external exchange to try this strategy. Yeah, but I guess I'm just looking from a volume perspective of what they actually need. In your simulations, was there a drop-off point where, let's say, if they only had 100k versus 500k, it's no longer profitable? Yeah, actually, sometimes you need very large inventories to realize very large price difference. But we didn't go into this we assume that you always have enough but you're right that to take this advantage you can check numbers to take very large advantage you need very large inventory as well so that was the last question thank you very much for your talk please give a",
"eventId": "devcon-7",
- "slot_start": 1731474000000,
- "slot_end": 1731475800000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1ZVK2vJYrK2rxz9r6LEc4JhYeEu_tVk_8Q4kLDWRxY9k"
+ "slot_start": 1731487200000,
+ "slot_end": 1731487800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1CjpmVDcW4MOjilttmNcrYu_KP0rC8ud1_BjudHV_ntI",
+ "resources_slides": null,
+ "speakers": [
+ "akaki-mamageishvili"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
6,
@@ -473020,13 +472035,13 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -473335,6 +472350,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -473344,7 +472360,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -473368,6 +472383,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -473400,7 +472416,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -473416,6 +472431,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -473723,7 +472739,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -473734,6 +472749,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -473914,37 +472931,39 @@
},
{
"session": {
- "id": "l2-specific-mev-mitigation-strategies",
- "sourceId": "FFWJAV",
- "title": "L2 Specific MEV Mitigation Strategies",
- "description": "MEV mitigation and prevention has primarily been researched in the base L1 Ethereum layer. This talk explores L2 specific strategies, including the future in the event of decentralized sequencing. We explore emerging EIP proposals and drafts (EIP-7640), the use of intents in L2s and other new constructions.",
- "track": "Layer 2",
- "type": "Talk",
+ "id": "launching-projects-out-of-the-global-majority",
+ "sourceId": "7VZ8WH",
+ "title": "Launching Projects out of the Global Majority",
+ "description": "Launching projects has been an almost entirely US driven exercise, with a handful of expectations out of Europe and Asia - and basically 0 examples out of LATAM or Africa. This talk aims to shed light on why this is a reality and how we as an ecosystem can support more experimentation and launches out of the global majority. Talking through cryptoeconomics, investors, narrative and positioning of previous high impact project launches.",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Business",
"featured": false,
- "doNotRecord": false,
+ "doNotRecord": true,
"keywords": [
- "DeFi"
+ "Global"
],
"tags": [
- "Layer 2s",
- "Rollups",
- "MEV",
- "defi",
- "Layer 2s",
- "MEV",
- "Rollups"
+ "DAO",
+ "Sufficient decentralization",
+ "Best Practices",
+ "macro/micro economics",
+ "global",
+ "Best Practices",
+ "DAO",
+ "macro/micro economics",
+ "Sufficient decentralization"
],
"language": "en",
"speakers": [
- "joseph-poon"
+ "james-waugh"
],
"eventId": "devcon-7",
- "slot_start": 1731646800000,
- "slot_end": 1731648600000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1WzPEAvLhXYIe49IEB4HEC3EgI2OglZ-ElusjYDJG2QY"
+ "slot_start": 1731478800000,
+ "slot_end": 1731479400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1BZ-1nzUuvITdZkK8Kxj9N_dkxHmkmlG75RJ7u4tbtAc"
},
"vector": [
0,
@@ -473953,7 +472972,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -474389,17 +473407,9 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -474701,7 +473711,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -474737,11 +473746,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -474765,7 +473774,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -474808,6 +473816,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -474863,6 +473872,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -474890,7 +473900,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -474919,6 +473928,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -475108,6 +474118,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -475260,7 +474272,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -475272,6 +474283,11 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -475282,57 +474298,42 @@
},
{
"session": {
- "id": "latency-advantage-in-cex-dex-arbitrage",
- "sourceId": "RPMHLF",
- "title": "Latency Advantage in CEX-DEX Arbitrage",
- "description": "We study the effects of having latency advantage in the CEX-DEX arbitrage in the first-come first-serve transaction ordering policies. We search for optimal strategies for a trader that owns such advantage. To find optimal strategies, we simulate price changes on CEX using real data and assume DEX price does not change in the latency advantage interval. We find that optimal strategy can even be to trade right away as soon as the price difference crosses a threshold where trading is profitable",
- "track": "Cryptoeconomics",
- "type": "Lightning Talk",
+ "id": "lazarus-how-to-stay-safe-from-the-biggest-threat-actor-in-crypto",
+ "sourceId": "HCXCXB",
+ "title": "Lazarus! How to stay safe from the biggest threat actor in crypto",
+ "description": "Lazarus has stolen by far the most funds in the blockchain space. They use the same or very similar attack vectors every time yet we see the biggest crypto companies falling victim to them one after another.\r\n\r\nIn this talk, i'll go over some of the attack vectors used by Lazarus and how people can keep themselves safe from Lazarus.",
+ "track": "Security",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Rollups",
- "Economics",
- "MEV",
- "AMMs",
- "programming",
- "dynamic",
- "AMMs",
- "Economics",
- "MEV",
- "Rollups"
- ],
"keywords": [
- "Optimal",
- "Stopping;",
- "Dynamic",
- "Programming;"
+ "Lazarus"
+ ],
+ "tags": [
+ "Security",
+ "Best Practices",
+ "Hacks",
+ "lazarus",
+ "Best Practices",
+ "Hacks",
+ "Security"
],
- "duration": 562,
"language": "en",
- "sources_swarmHash": "373cd46037e49db5d6daf67c74b2a86e58ffe6dbe5747c1938a919384ce69f95",
- "sources_youtubeId": "9r7hmxQ8DTA",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673468a09dbb7a90e188a277.vtt",
- "transcript_text": " . Hello everyone. Welcome to the presentation. Today, I will talk about MEV capture through time advantage arbitrage. So this is the title of the paper that we wrote together with Ed Felten, Robin Frisch, Maria Silva, and Benjamin Lifshitz. This is different from the title of the session. So take your time to take a picture or write it down. It will be gone. I cannot go really back. So initially, I submitted it as a 20-minute presentation, but it was demoted to five minutes. So the only thing I can do is to motivate you to read the paper. And I hope I can do that. Okay, so main part, motivation. So we tried to understand what TimeBoost does to MEV, and to give you a very quick introduction in the TimeBoost, this is selling Fastlane license that allows one player to have 200 millisecond advantage over all other players and this advantage lasts only for one minute and after one minute there will be another auction. Then advantages of course achieved by delaying all the other transactions by other users. And we want to understand the arbitrage between automated market makers and outside markets. So we have a lot of assumptions in order to derive our few theoretical results and many simulation results. So we assume that in the outside markets fees are very low or let's say zero, and the price discovery happens on the external market. On the IMM that is on the chain, it's only arbitrage transactions. Of course, there are some noise transactions as well, but we assume that they can go into both directions, so they cancel the effects. We also assume the efficient market assumption which is that the price depends only on the current, so price change doesn't depend on the previous price changes, so it's a pure random process which is of course not true in reality and we even observed on the data that it's not true. So the model looks like this, We have this one player that has this time advantage during time t. There are two assets, one risky asset and the numeraire. Think of as Ether risky asset and numeraire USD or the other way around. The AMM has a trading fee and the risky assets price changes on the outside market. So initially we assume initially of the simulation we assume that they are the same, the prices are the same, and then once the arbitrage opportunity arises on the outside market, so price moves, then arbitrage needs to decide when to capitalize on it. And we assume that it has only time advantage time so after this time passes opportunity will be taken away by other arbitrage and this is a conservative assumption for the arbitrage value so this reduces to an optimization problem so So we have time advantage arbitrage here, and we have three parameters that give a state. What is the current price difference, relative time, so price difference? How much time passed in this 200 millisecond? And how much time passed in the total period time? And we need to decide between trading, so taking the arbitrage, or waiting. And the punchline here is that dynamic programming solves this problem. And with dynamic programming, we simulate it on the real data. So we took, let's say, Ethereum USDT market on the Binance, and we step size 10 millisecond. We have advantage window 200 millisecond and total time one minute. And we can calculate for each point, internal point. We can calculate what is the optimal move and also what is the average gains, average arbitrage value. And we obtained the observation that waiting till the end of this advantage time is mostly optimal, but not always. So there are some cases when it's not optimal. So I will not give you any numbers, because that's the only thing that people remember in the end, how much money time boost makes with these assumptions. But it gives some upper bound on this type of arbitrage, so decentralized exchange arbitrage. Additionally to this, we also looked into opportunity to let the pool contract know about time boosted transactions which allows them to price such transactions differently and this introduces some interesting game between LPS and the time advantage the arbitrage and then we can calculate what will be the distribution of value between these two and other arbitrage years so thank you for your attention happy to answer questions about this and the time boost in general. Thank you very much. So raise your hand if you have any questions. Yep, over there. There first. Oops, sorry. Sorry. Thanks. Do you think it's a good idea to use one minute allocation for arbitrage? Is this too long? Have you tried to do shorter simulation times? I ask for, because MEV, multi-block MEV has been a problem. We don't understand it very well. So have you tried to simulate shorter? So we, in simulation, of course, you can simulate and get results, what you get. But we thought that one minute is not very long, because if you make it longer, it's even worse from your perspective. But if you make it shorter, we need to conduct this auction too frequently. And that also has some cost. So that was this kind of trade-off that we analyzed. There's another question over there. Did you try this using real money, and did you find anything interesting between real and simulation? So we didn't try real money, but you are welcome to try. We analyzed the backtesting, so this data was taken in July. But in principle, you can forward test that too once once it's there but you can also forward without time post deployed on arbitrum you can just assume that you have this advantage and you can then see how much you can make with the strategies that we suggest so answer is it's very easy to do, but we didn't do it. Hi, this is Kenneth, and I'm not sure if you covered it, but was any differential gas price that was taken into consideration in your simulation? So what differential I didn't get? Gas. Amount gas fees. Or decentralized exchange. Decentralization. Yeah. The gas fees. Ah. So gas fees we assume to be, let's say, sub-cent for the exchange. So we took realistic gas fees and subtracted from the gains. But they are very not substantial for the results. I see. Thank you. There's one last question over there. Oh, over there? Okay. Over there, yeah. Yeah. What kind of inventory is needed to actually pull this off in a relatively profitable manner? I mean, you need to have both assets on the chain and on the external exchange to try this strategy. Yeah, but I guess I'm just looking from a volume perspective of what they actually need. In your simulations, was there a drop-off point where, let's say, if they only had 100k versus 500k, it's no longer profitable? Yeah, actually, sometimes you need very large inventories to realize very large price difference. But we didn't go into this we assume that you always have enough but you're right that to take this advantage you can check numbers to take very large advantage you need very large inventory as well so that was the last question thank you very much for your talk please give a",
- "eventId": "devcon-7",
- "slot_start": 1731487200000,
- "slot_end": 1731487800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1CjpmVDcW4MOjilttmNcrYu_KP0rC8ud1_BjudHV_ntI",
- "resources_slides": null,
"speakers": [
- "akaki-mamageishvili"
- ]
+ "mudit-gupta"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731580200000,
+ "slot_end": 1731582000000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/15zVK369DMEaAyZgEYl7ytDPnVtTcqgBbNjAZaVtPUfk"
},
"vector": [
+ 6,
0,
0,
- 6,
0,
0,
0,
@@ -475773,8 +474774,8 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -476079,12 +475080,12 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -476110,6 +475111,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -476117,14 +475119,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -476165,7 +475165,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -476331,6 +475330,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -476485,8 +475485,6 @@
0,
0,
2,
- 2,
- 0,
0,
0,
0,
@@ -476647,7 +475645,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -476660,49 +475657,49 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "launching-projects-out-of-the-global-majority",
- "sourceId": "7VZ8WH",
- "title": "Launching Projects out of the Global Majority",
- "description": "Launching projects has been an almost entirely US driven exercise, with a handful of expectations out of Europe and Asia - and basically 0 examples out of LATAM or Africa. This talk aims to shed light on why this is a reality and how we as an ecosystem can support more experimentation and launches out of the global majority. Talking through cryptoeconomics, investors, narrative and positioning of previous high impact project launches.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
+ "id": "learn-huff-to-become-an-evm-chad",
+ "sourceId": "HRMCBK",
+ "title": "Learn Huff to become an EVM chad",
+ "description": "Become an EVM chad by learning Huff, a low level assembly language for the EVM! On top of being able to write super duper optimized smart-contracts, Huff will teach you how the EVM works under the hood and will let you master high level languages like Solidity or Vyper.",
+ "track": "Developer Experience",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Business",
+ "audience": "Developper",
"featured": false,
- "doNotRecord": true,
+ "doNotRecord": false,
"keywords": [
- "Global"
+ "Education",
+ "Huff",
+ "Programming"
],
"tags": [
- "DAO",
- "Sufficient decentralization",
+ "Tooling",
+ "Languages",
+ "Open Source Software",
"Best Practices",
- "macro/micro economics",
- "global",
+ "programming",
"Best Practices",
- "DAO",
- "macro/micro economics",
- "Sufficient decentralization"
+ "Languages",
+ "Open Source Software",
+ "Tooling"
],
"language": "en",
"speakers": [
- "james-waugh"
+ "clement-lakhal"
],
"eventId": "devcon-7",
- "slot_start": 1731478800000,
- "slot_end": 1731479400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1BZ-1nzUuvITdZkK8Kxj9N_dkxHmkmlG75RJ7u4tbtAc"
+ "slot_start": 1731564000000,
+ "slot_end": 1731571200000,
+ "slot_roomId": "classroom-d",
+ "resources_presentation": "https://docs.google.com/presentation/d/1-l5GZfkJD_jGXx19MZKctGeyeRotdNV_0HKanpnUjLU"
},
"vector": [
- 0,
- 0,
- 0,
0,
0,
0,
@@ -477144,12 +476141,11 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -477474,6 +476470,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -477549,11 +476546,13 @@
0,
0,
0,
+ 2,
+ 2,
+ 0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -477609,7 +476608,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -477665,7 +476663,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -477853,10 +476850,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -478020,12 +477017,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -478035,40 +477032,33 @@
},
{
"session": {
- "id": "lazarus-how-to-stay-safe-from-the-biggest-threat-actor-in-crypto",
- "sourceId": "HCXCXB",
- "title": "Lazarus! How to stay safe from the biggest threat actor in crypto",
- "description": "Lazarus has stolen by far the most funds in the blockchain space. They use the same or very similar attack vectors every time yet we see the biggest crypto companies falling victim to them one after another.\r\n\r\nIn this talk, i'll go over some of the attack vectors used by Lazarus and how people can keep themselves safe from Lazarus.",
- "track": "Security",
+ "id": "lessons-and-learning-in-people-ops-at-the-ef",
+ "sourceId": "D7V8ZY",
+ "title": "Lessons & Learning in People Ops at the EF",
+ "description": "In this talk, you will learn more about the learnings of People Ops at the EF gathered after the first two years of its existence. \r\n\r\nWe will discuss the differences between People Ops in an open and decentralized setting, such as the EF and centralized, traditional organizations, and the required differences in approach and tradeoffs.",
+ "track": "Coordination",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Lazarus"
- ],
- "tags": [
- "Security",
- "Best Practices",
- "Hacks",
- "lazarus",
- "Best Practices",
- "Hacks",
- "Security"
+ "people",
+ "growth",
+ "open"
],
+ "tags": [],
"language": "en",
"speakers": [
- "mudit-gupta"
+ "jose-pedro-cabrita"
],
"eventId": "devcon-7",
- "slot_start": 1731580200000,
- "slot_end": 1731582000000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/15zVK369DMEaAyZgEYl7ytDPnVtTcqgBbNjAZaVtPUfk"
+ "slot_start": 1731652800000,
+ "slot_end": 1731654000000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1pSqd-PaSLhWa3-GQ2HCRVcJCWv_fnu9Z5T4wVlAMT-c"
},
"vector": [
- 6,
0,
0,
0,
@@ -478080,6 +477070,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -478820,8 +477812,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -478851,7 +477841,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -479071,7 +478060,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -479225,7 +478213,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -479381,7 +478368,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -479392,6 +478378,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -479403,47 +478391,41 @@
},
{
"session": {
- "id": "learn-huff-to-become-an-evm-chad",
- "sourceId": "HRMCBK",
- "title": "Learn Huff to become an EVM chad",
- "description": "Become an EVM chad by learning Huff, a low level assembly language for the EVM! On top of being able to write super duper optimized smart-contracts, Huff will teach you how the EVM works under the hood and will let you master high level languages like Solidity or Vyper.",
- "track": "Developer Experience",
- "type": "Workshop",
- "expertise": "Intermediate",
- "audience": "Developper",
+ "id": "lessons-from-integrating-logup-gkr-in-the-miden-vm",
+ "sourceId": "LL799L",
+ "title": "Lessons from integrating LogUp-GKR in the Miden VM",
+ "description": "In this talk we will describe how to modify the STARK protocol to prove multiset checks using the GKR protocol. We will take a deep dive of the approach we’ve taken to implement it in the Miden VM, covering the benefits and challenges we've experienced.",
+ "track": "Applied Cryptography",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Education",
- "Huff",
- "Programming"
+ "LogUp",
+ "GKR"
],
"tags": [
- "Tooling",
- "Languages",
- "Open Source Software",
- "Best Practices",
- "programming",
- "Best Practices",
- "Languages",
- "Open Source Software",
- "Tooling"
+ "Zero-Knowledge",
+ "Cryptography",
+ "gkr",
+ "Cryptography",
+ "Zero-Knowledge"
],
"language": "en",
"speakers": [
- "clement-lakhal"
+ "philippe-laferriere"
],
"eventId": "devcon-7",
- "slot_start": 1731564000000,
- "slot_end": 1731571200000,
- "slot_roomId": "classroom-d",
- "resources_presentation": "https://docs.google.com/presentation/d/1-l5GZfkJD_jGXx19MZKctGeyeRotdNV_0HKanpnUjLU"
+ "slot_start": 1731470400000,
+ "slot_end": 1731472200000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Eh_tW-ueqILgRF3_daF57cyNlIe38F86K1969SSn5sg"
},
"vector": [
0,
0,
0,
- 6,
0,
0,
0,
@@ -479451,6 +478433,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -480200,6 +479184,17 @@
0,
0,
0,
+ 6,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -480213,7 +479208,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -480223,7 +479217,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -480289,16 +479282,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -480754,6 +479737,7 @@
0,
0,
2,
+ 2,
0,
0,
0,
@@ -480765,48 +479749,49 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0
]
},
{
"session": {
- "id": "lessons-and-learning-in-people-ops-at-the-ef",
- "sourceId": "D7V8ZY",
- "title": "Lessons & Learning in People Ops at the EF",
- "description": "In this talk, you will learn more about the learnings of People Ops at the EF gathered after the first two years of its existence. \r\n\r\nWe will discuss the differences between People Ops in an open and decentralized setting, such as the EF and centralized, traditional organizations, and the required differences in approach and tradeoffs.",
- "track": "Coordination",
- "type": "Talk",
+ "id": "leveraging-ethereum-for-sustainable-solutions-in-southeast-asia",
+ "sourceId": "F7Z87P",
+ "title": "Leveraging Ethereum for Sustainable Solutions in Southeast Asia",
+ "description": "In this talk you will learn how Ethereum can shape a sustainable and regenerative future in Southeast Asia. We will dive into the challenges faced by communities like Thai farmers, and how cryptoeconomic solutions can drive resilience, fair markets, and renewable energy adoption. Discover innovative projects tackling coordination failures through cryptoeconomics, from parametric insurance to decentralized energy exchanges, and see how you can contribute to this transformative vision.",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Local/SEA",
"featured": false,
"doNotRecord": false,
"keywords": [
- "people",
- "growth",
- "open"
+ "Ethereum",
+ "Use",
+ "Cases"
+ ],
+ "tags": [
+ "Ethereum for Good",
+ "Climate",
+ "SEA",
+ "ethereum",
+ "case",
+ "use",
+ "Climate",
+ "Ethereum for Good",
+ "SEA"
],
- "tags": [],
"language": "en",
"speakers": [
- "jose-pedro-cabrita"
+ "gesa-schneider"
],
"eventId": "devcon-7",
- "slot_start": 1731652800000,
- "slot_end": 1731654000000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1pSqd-PaSLhWa3-GQ2HCRVcJCWv_fnu9Z5T4wVlAMT-c"
+ "slot_start": 1731574200000,
+ "slot_end": 1731574800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/103WQKb3Z0-Knd415-KUFx0TbNISdUujVoQzaXW3xd3Q"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -481249,16 +480234,13 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -481685,6 +480667,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -481693,6 +480676,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -481800,6 +480784,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -481863,12 +480848,14 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -482124,7 +481111,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -482132,41 +481118,45 @@
0,
0,
0,
+ 2,
0
]
},
{
"session": {
- "id": "lessons-from-integrating-logup-gkr-in-the-miden-vm",
- "sourceId": "LL799L",
- "title": "Lessons from integrating LogUp-GKR in the Miden VM",
- "description": "In this talk we will describe how to modify the STARK protocol to prove multiset checks using the GKR protocol. We will take a deep dive of the approach we’ve taken to implement it in the Miden VM, covering the benefits and challenges we've experienced.",
+ "id": "leveraging-high-performance-computing-for-efficient-stark-provers",
+ "sourceId": "ZGXYDF",
+ "title": "Leveraging High-Performance Computing for Efficient STARK Provers",
+ "description": "Zero-Knowledge Proof (ZKP) protocols' applicability hinges on the prover's ability to efficiently generate proofs. This talk explores the computational aspects affecting ZKP performance, specifically focusing on STARK provers. We will analyze performance across high-performance and standard computing architectures and interpret results by examining key workload characteristics. From this understanding, we can project ZKP capabilities in future scenarios.",
"track": "Applied Cryptography",
"type": "Talk",
- "expertise": "Expert",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "LogUp",
- "GKR"
+ "computing performance",
+ "optimization",
+ ""
],
"tags": [
- "Zero-Knowledge",
- "Cryptography",
- "gkr",
- "Cryptography",
- "Zero-Knowledge"
+ "ZK-EVMs",
+ "ZKP",
+ "STARK",
+ "optimization",
+ "STARK",
+ "ZK-EVMs",
+ "ZKP"
],
"language": "en",
"speakers": [
- "philippe-laferriere"
+ "ricard-borrell"
],
"eventId": "devcon-7",
- "slot_start": 1731470400000,
- "slot_end": 1731472200000,
+ "slot_start": 1731477600000,
+ "slot_end": 1731479400000,
"slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1Eh_tW-ueqILgRF3_daF57cyNlIe38F86K1969SSn5sg"
+ "resources_presentation": "https://docs.google.com/presentation/d/1J3KMOMYAXjSesFqZthBz2neGQcOt3Ui_KyKgToVj0Z0"
},
"vector": [
0,
@@ -482617,12 +481607,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -482933,8 +481919,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -482999,6 +481983,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -483134,6 +482119,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -483269,6 +482255,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -483327,7 +482315,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -483482,11 +482469,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
2,
- 2,
0,
0,
0,
@@ -483504,41 +482491,36 @@
},
{
"session": {
- "id": "leveraging-ethereum-for-sustainable-solutions-in-southeast-asia",
- "sourceId": "F7Z87P",
- "title": "Leveraging Ethereum for Sustainable Solutions in Southeast Asia",
- "description": "In this talk you will learn how Ethereum can shape a sustainable and regenerative future in Southeast Asia. We will dive into the challenges faced by communities like Thai farmers, and how cryptoeconomic solutions can drive resilience, fair markets, and renewable energy adoption. Discover innovative projects tackling coordination failures through cryptoeconomics, from parametric insurance to decentralized energy exchanges, and see how you can contribute to this transformative vision.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Local/SEA",
+ "id": "libp2p-implementation-in-c-and-prysm",
+ "sourceId": "F7UVJP",
+ "title": "Libp2p implementation in C# and Prysm",
+ "description": "Joint talk will discuss a project which split to work on the C# implementation of Nethermind's libp2p, where we implemented the TLS protocol, upgraded the Noise protocol, and added the Perf protocol. Although the first version of the C# implementation isn’t released yet, it is integrated with Gnosis Chain’s Shutter node. Second part of the talk focuses on new goland libp2p library for Prysm CL client",
+ "track": "[CLS] EPF Day",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Ethereum",
- "Use",
- "Cases"
+ "Libp2p",
+ "Networking",
+ "P2P"
],
"tags": [
- "Ethereum for Good",
- "Climate",
- "SEA",
- "ethereum",
- "case",
- "use",
- "Climate",
- "Ethereum for Good",
- "SEA"
+ "Consensus",
+ "Network State"
],
"language": "en",
"speakers": [
- "gesa-schneider"
+ "rose",
+ "richa",
+ "kira"
],
"eventId": "devcon-7",
- "slot_start": 1731574200000,
- "slot_end": 1731574800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/103WQKb3Z0-Knd415-KUFx0TbNISdUujVoQzaXW3xd3Q"
+ "slot_start": 1731476700000,
+ "slot_end": 1731477600000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/114N7ZFoxay5HlB8T-LpY8iCOTKX70658i91W43eXDpc"
},
"vector": [
0,
@@ -483547,8 +482529,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -483558,6 +482538,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -483696,6 +482677,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -483822,6 +482804,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -484294,6 +483277,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -484335,6 +483319,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -484419,7 +483404,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -484428,7 +483412,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -484537,7 +483520,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -484601,14 +483583,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -484853,6 +483833,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -484869,46 +483850,48 @@
0,
0,
0,
- 0,
- 2,
0
]
},
{
"session": {
- "id": "leveraging-high-performance-computing-for-efficient-stark-provers",
- "sourceId": "ZGXYDF",
- "title": "Leveraging High-Performance Computing for Efficient STARK Provers",
- "description": "Zero-Knowledge Proof (ZKP) protocols' applicability hinges on the prover's ability to efficiently generate proofs. This talk explores the computational aspects affecting ZKP performance, specifically focusing on STARK provers. We will analyze performance across high-performance and standard computing architectures and interpret results by examining key workload characteristics. From this understanding, we can project ZKP capabilities in future scenarios.",
- "track": "Applied Cryptography",
- "type": "Talk",
+ "id": "light-client-support-in-prysm",
+ "sourceId": "9PC3EY",
+ "title": "Light Client Support in Prysm",
+ "description": "Showcasing the addition of Light Client server support to the Prysm consensus client.",
+ "track": "[CLS] EPF Day",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "computing performance",
- "optimization",
- ""
- ],
"tags": [
- "ZK-EVMs",
- "ZKP",
- "STARK",
- "optimization",
- "STARK",
- "ZK-EVMs",
- "ZKP"
+ "EPF",
+ "Consensus",
+ "Light Clients"
],
- "language": "en",
- "speakers": [
- "ricard-borrell"
+ "keywords": [
+ "Prysm"
],
+ "duration": 724,
+ "language": "en",
+ "sources_swarmHash": "87a24b2a455f641db3325c1e58fa4d6f7aa331c6e585835bb8a48f1ac01635a0",
+ "sources_youtubeId": "d7j5WwTkZYs",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343f059dbb7a90e1ea95b6.vtt",
+ "transcript_text": " . So, hey everyone, I'm Preston. Hey everyone, I'm Rupam. We have been working on integrating life's client server-side support in Prism. For the project intro, light nodes are basically nodes which you can run, which you use significantly less resources than a full node. But there are some drawbacks. How a light line works is basically they maintain this chain of block headers until the latest block header. We get this trusted block root, which is available in the network. And using that, we can fetch a range of updates. After that we get the root hash which is, which can basically be used to determine the latest block header. So there's this reference of the like clients after the merge by Ethan. It was covered in Defcon six, I guess. Yeah. So you can check it out. It's really nice. Yeah, so if we're looking at what a Lite Client update looks like, it's a simple structure. It contains the block header, so the Lite Client can basically save that block header. It has the current sync committee public keys. The sync committee is the 512 validators that sign each block header, and the light clients basically verify that block header by checking the sync committee signature, and there's also something else called the sync committee bits, which shows which of these 512 validators actually did sign the block header. And also there is this next sync committee, which is the sync committee, the 512 sync committee for the next period. So you can basically check when you get the next block header that the signature checks out, and this is actually part of the chain. So how the network works right now is that we have this beacon network, which full nodes talk to each other and connect to each other. And we have a light node on the side, which basically asks one of the full nodes for these updates over and over again to be able to stay synced. And then we have this RPC provider that we might not trust. So what a light node, what a light client actually does is that it gets the data from that RPC. But instead of just trusting it, it checks it against the state route that it gets from the full nodes. And what we did in this project was basically implementing that part, which is how the light node talks to a full node and gets those updates. Yeah. And there are four endpoints. The first one, the bootstrap using the block route. You have the trusted block route in the network and you can just call the bootstrap on that block route and after that, yeah, you get a range of three updates, let's say three here, and when the light client has synced up to the latest block header, you can just keep calling optimistic update or finality update according to your needs. Yeah, so the project faces that we had was we got familiar with Prism and how light clients work. And then we started implementing the specs and then going back and forth with testing and debugging. This is nice, but this is a lie. This is how it actually is. So everything was weird. But, yeah, so the current state of the project is that we implemented the four RPC endpoints and we implemented that for like forks after alter, which is all the forks that support light clients. We implemented two databases, one for light client updates and one for light client bootstraps to store them and not have to manually compute them each time. And also we implemented saving updates and bootstrap when receiving new blocks. Unfortunately we haven't still implemented saving them while syncing. And also the P2P events and topics were implemented. So these functions are not only exposed through the beacon RPC, they are exposed through the P2P network as well. And these are all visible on the EPF Lite Client branch on Prism. Oh yeah, we have a, well, kind of demo. So these are old, but this is the Nimbus server, and this is our server. If we reload them at the same time, if we are lucky, we get the same result. Yeah, kind of the same result. And so the difference, as you can see, is that we have this bug which gives us three more execution branches, and we have to debug and see why. Yeah, but mainly we can see that this is just one of the RPC endpoints, but this is for the demo. They're mainly working correctly. Okay. Yeah. As of the next steps, we do have some work left. And the first of all would be we would need to test it out on a testnet. And, of course, like, measure the test performance and optimize it according to that. As also Bastian said before, like, we still don't save updates or bootstrap while syncing, which would be nice to have. So we do plan to add that too. And after that, yeah, adding like client stuff to E2A tests and code doses, yeah. That's for mainly for testing for all the forks. So that's what the next steps and yeah almost all consensus layers support like lines now including Nimbus, Loadstar. So yeah Prism is also into the game now. A special thanks to Radek and Josh and Mario for the cohort and Radek for the awesome mentoring here. Thank you Thank you very much Thank you very much guys. Yeah, I really appreciate you sharing all of this. Do we have any question for Bustin Rupam? Yeah Excuse me, I have to scream. Do you know if there's any plans to add endpoints to generate proofs? Sorry, add what? To add proofs. So, like the light line data set is very limited. There's proofs to prove the execution branch and the finalized header. But say you wanted to prove something else in the beacon state, like block roots. What would be super useful if there was an endpoint to say, I want to prove block roots at this index and just return the hash? I feel like that's super missing from the lifeline spec. So there are multiple EIPs open right now that work on adding, getting proofs from the execution clients, not the consensus clients. But yeah, there are multiple open PRs, I think at least four, that point to different parts of the block where you can get different proofs and then validate them using all these routes that are in the block header. Okay, but no beacon state proofs yet? Beacon state proofs? We have the state root hash in the block header. So if you have the proofs and if you have the data, you can check that against the state root. Yeah, but so what I mean is like, say you want to prove anything in the beacon state. At the moment, you need to download the whole beacon state as a Yeah, but so what I mean is like, say you want to prove anything in the beacon state, at the moment you need to download the whole beacon state is a Z, right? And then you have to like create the tree and then generate the proof ashes yourself. But like for instance, load star has an endpoint where you can say I want to prove this piece of the beacon state and then they just return the proof. That would be really cool if all the clients can add it because I think sometimes the apps using the light line data can't get to all the data that you'd actually need. For instance, I work on a bridge project and we need to prove, if you have a finalized header, that another header is an ancestor of that block. And you need the block roots proofs to do that. But it's missing from the light line data. Yeah, that is true. I don't think there is such a thing in Prism right now. But maybe... Hi, I'm from Prism. So, yeah, recently, actually, we had another person asking us the same question. So we're actively looking into that. So even if it's not in an official light client, like future plans for official specification, it's definitely another point I would like to add. So we can talk to Nimbus how they do that. And I think in the next few months, I hope we will have something to share with everyone. Awesome. That's great news. Thanks. Thank you so much, Radek. I just wanted to say thank you for this project. I had lost all hope of Prism ever supporting the Light Lion, so thank you. Awesome. Okay, quite a quick question. Maybe my understanding in proofs and stuff is quite limited, but can you, for example, bootstrap your light node from consensus client and then start to query the RPC provider for the latest data? So you would unload basically all the RPC calls from consensus clients? So you could use, if I'm understanding your question correctly, you're asking if you can, instead of asking the RPC providers for data, ask consensus node for data? No? Okay. asking the RPC providers for data, ask consensus node for data. No? Okay. The other way around. As I understood, you get the latest block data, like finalized... Block header. Latest block headers from the consensus node, yes. But can you do this from RPC clients? Well, yes, I think so. You can do that. But the point is that you basically check and verify all these updates one by one using the sync committee signature. So it doesn't really matter where you get those updates from as long as you have everyone in order from where you start. And this is all dependent on if your first trusted block route is actually part of the chain. So if you've been tricked to use something that's not on the chain and is on a fake chain, then you will keep up on that and you won't know what's wrong. But yeah, you can definitely get the updates from anywhere and just verify them one by one. Okay, awesome. Thank you so much, guys. Maybe one more question or comment or anything? Otherwise, yeah, huge thanks again. Thank you so much for all your work, all your contributions and the presentation. Thanks. Thank you very much.",
"eventId": "devcon-7",
- "slot_start": 1731477600000,
- "slot_end": 1731479400000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1J3KMOMYAXjSesFqZthBz2neGQcOt3Ui_KyKgToVj0Z0"
+ "slot_start": 1731475800000,
+ "slot_end": 1731476700000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1o1_9VdMiq5Uf_dyQTPf5R3mVbxhL4d0QI33ZiZNm28Q",
+ "resources_slides": null,
+ "speakers": [
+ "bastin",
+ "rupam"
+ ]
},
"vector": [
0,
@@ -484921,12 +483904,13 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -485362,6 +484346,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -485663,6 +484648,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -485677,6 +484663,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -485738,7 +484728,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -485874,7 +484863,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -485958,6 +484946,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -486011,22 +485007,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -486246,36 +485226,47 @@
},
{
"session": {
- "id": "libp2p-implementation-in-c-and-prysm",
- "sourceId": "F7UVJP",
- "title": "Libp2p implementation in C# and Prysm",
- "description": "Joint talk will discuss a project which split to work on the C# implementation of Nethermind's libp2p, where we implemented the TLS protocol, upgraded the Noise protocol, and added the Perf protocol. Although the first version of the C# implementation isn’t released yet, it is integrated with Gnosis Chain’s Shutter node. Second part of the talk focuses on new goland libp2p library for Prysm CL client",
- "track": "[CLS] EPF Day",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "lighthouse-introduction-to-siren",
+ "sourceId": "F3ZPRJ",
+ "title": "Lighthouse: Introduction to Siren",
+ "description": "Sigma Prime would like to introduce Lighthouse's official user interface called Siren. Siren was made to monitor performance, display key metrics and help make lighthouse validator management easy. Siren comes with built in metrics, logging, and other features users will find useful when updating their validator.",
+ "track": "Usability",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Stakers/Validators",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Libp2p",
- "Networking",
- "P2P"
- ],
"tags": [
- "Consensus",
- "Network State"
+ "Home staking",
+ "UI/UX",
+ "Accessibility",
+ "ui",
+ "Accessibility",
+ "Home staking",
+ "UI/UX"
],
- "language": "en",
- "speakers": [
- "rose",
- "richa",
- "kira"
+ "keywords": [
+ "lighthouse",
+ "UI"
],
+ "duration": 388,
+ "language": "en",
+ "sources_swarmHash": "581e106f3b22dfacc1d56771706969f972348e514d3d6a94afc75aac47317df4",
+ "sources_youtubeId": "RhlKmJqk0go",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673338d13a168eb535e44173.vtt",
+ "transcript_text": " Good afternoon. I am Maverick. I am a Lighthouse engineer working at Sigma Prime. Lighthouse is a consistent client maintaining around 33% of the entire Ethereum network and today we want to introduce Siren. Before we get started I want to ask a couple of questions. Who here feels confident they can set up and configure a validator all on their own? Okay. Who here feels they would struggle to set up a validator, even if they had a video tutorial and a guide. Okay, if that's you, don't worry. It's okay. It's totally normal to feel like you're not technical enough to maintain a validator. As a matter of fact, Lighthouse has plenty of people that self-identify as noobs validating the network, and we always encourage them to participate and to ask questions when no prior knowledge required. And this is kind of the reason why we, what led us to make Insiren. We believe staking can be easy, accessible, and reliable. If an increase in home validators leads to more decentralization which increases Ethereum security then we must work hard to lower the technical barrier of entry preventing average users from committing to become validators. Okay so this is Siren. With this goal and user profile in mind we created a user interface that will help solo stakers at home. You can track validators, you can track statuses, log updates, and much more all in one location on our super sexy dashboard that comes in light and dark mode. With minimal configuration, Siren connects directly to your Lighthouse Validator client and your beacon node, allowing to communicate and consume data securely. Users have the option to install Siren via our Sigma Prime Docker containers or to download it and build it locally for some of our super users out there. Once activated, Siren allows you to manage your validators from any device on your home network or externally using an SSH or VPN access. So let's go over some features already out on Siren. It's super easy to track your value sync statuses, to get a breakdown of your total rewards, which includes ETH currency rates and earning estimates. You can get an aggregated value list that checks on the status the balance of aggregated of rewards and etc keep track of disk base CPU usage RAM usage on the machine that's running Lighthouse you can see how long your nodes have been running if you have warnings telling you if you're falling behind blocks, peer data. Some key more features are you can get notified of critical and error logs, which includes statistics on rates. You can monitor logs as they arrive in real time and use the search bar and find specific log data to copy and paste log information into the Discord if you need help. So what are some of the key actions? You can update your validator graffiti at the click of a button. For those OG validators with 00 withdrawal addresses, you can use SIREN to execute your BLS actions. And lastly, when you're ready, if you're ready to call it quits, in just a few steps, you can exit your validator safely and securely. All right, so what's next for Siren and what are we working on? Coming very, very soon, Siren will enable validated deposits. For those who already have a home validator, you may have used the Ethereum staking launchpad that create your validator. But through this, you are required to know the command line, you are required to make your own deposit JSON, your key stores, and import your validator into Lighthouse yourself. Now with Siren, there was supposed to be a video here, now withIREN you'll be able to take care of all of that on your own. SIREN condenses the entire flow into just a few steps, allowing full guidance and validation so you don't wreck yourself when you're moving 32 ETH. Hopefully soon 1 ETH when we reduce the fees down to 1 ETH. Okay, so we're preparing for the Pectra upgrade as well, EIP-7251. The upgrade will increase the max effective balance from 32 to 2048. This will enable validators to also consolidate. This will allow stakers to merge their validators together, which will help reduce operational overhead. And so Siren will enable this for all the Lighthouse users to be first in line in the consolidation queue the moment Pector goes live. And if you have any questions or you're interested, I'm going to reach out to the team. Just follow this and join us on Discord. We have a huge supportive community and a deaf team that will like to help out. This was made possible by the Sigma Prime team and that was it. It was lightning talk. I'm standing right behind you. We have one or two questions that I think we can handle in a minute. First question, what's best, light or dark mode? Dark mode. All right. This is rapid fire. Are there docs and how do I start using it? Yes, we do have docs. You can find them on the Lighthouse book. You just follow it and then there's a section for Siren itself.",
"eventId": "devcon-7",
- "slot_start": 1731476700000,
- "slot_end": 1731477600000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/114N7ZFoxay5HlB8T-LpY8iCOTKX70658i91W43eXDpc"
+ "slot_start": 1731408000000,
+ "slot_end": 1731408600000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1iWFucLqzajqGIcn5d4YFuRZ1zk1Y8VHURhoTiKQ1T-w",
+ "resources_slides": null,
+ "speakers": [
+ "ricki-moore"
+ ]
},
"vector": [
0,
@@ -486286,6 +485277,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -486293,8 +485285,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -486433,7 +485423,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -486560,7 +485549,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -486729,12 +485717,12 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -487035,7 +486023,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -487077,7 +486064,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -487091,6 +486077,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -487116,6 +486104,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -487435,6 +486424,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -487595,13 +486585,11 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -487613,10 +486601,10 @@
},
{
"session": {
- "id": "light-client-support-in-prysm",
- "sourceId": "9PC3EY",
- "title": "Light Client Support in Prysm",
- "description": "Showcasing the addition of Light Client server support to the Prysm consensus client.",
+ "id": "lighthouse-transition-journey-from-warp-to-axum",
+ "sourceId": "ZF79GZ",
+ "title": "Lighthouse transition journey : from warp to axum",
+ "description": "This talk will explore how to approach a significant refactor of the HTTP framework for lighthouse. \r\n\r\nIt will cover:\r\n- Measuring the performance of endpoints between Warp and Axum\r\n- A concrete plan for implementing the necessary changes",
"track": "[CLS] EPF Day",
"type": "Lightning Talk",
"expertise": "Intermediate",
@@ -487624,31 +486612,31 @@
"featured": false,
"doNotRecord": false,
"tags": [
- "EPF",
- "Consensus",
+ "Developer Infrastructure",
"Light Clients"
],
"keywords": [
- "Prysm"
+ "Performance",
+ "Developer",
+ "experience"
],
- "duration": 724,
+ "duration": 537,
"language": "en",
- "sources_swarmHash": "87a24b2a455f641db3325c1e58fa4d6f7aa331c6e585835bb8a48f1ac01635a0",
- "sources_youtubeId": "d7j5WwTkZYs",
+ "sources_swarmHash": "0ba36082c0dc4df92f95f85927da7080d528c36d541326d01a2f2c36606c619e",
+ "sources_youtubeId": "aIYhDRmoMdE",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343f059dbb7a90e1ea95b6.vtt",
- "transcript_text": " . So, hey everyone, I'm Preston. Hey everyone, I'm Rupam. We have been working on integrating life's client server-side support in Prism. For the project intro, light nodes are basically nodes which you can run, which you use significantly less resources than a full node. But there are some drawbacks. How a light line works is basically they maintain this chain of block headers until the latest block header. We get this trusted block root, which is available in the network. And using that, we can fetch a range of updates. After that we get the root hash which is, which can basically be used to determine the latest block header. So there's this reference of the like clients after the merge by Ethan. It was covered in Defcon six, I guess. Yeah. So you can check it out. It's really nice. Yeah, so if we're looking at what a Lite Client update looks like, it's a simple structure. It contains the block header, so the Lite Client can basically save that block header. It has the current sync committee public keys. The sync committee is the 512 validators that sign each block header, and the light clients basically verify that block header by checking the sync committee signature, and there's also something else called the sync committee bits, which shows which of these 512 validators actually did sign the block header. And also there is this next sync committee, which is the sync committee, the 512 sync committee for the next period. So you can basically check when you get the next block header that the signature checks out, and this is actually part of the chain. So how the network works right now is that we have this beacon network, which full nodes talk to each other and connect to each other. And we have a light node on the side, which basically asks one of the full nodes for these updates over and over again to be able to stay synced. And then we have this RPC provider that we might not trust. So what a light node, what a light client actually does is that it gets the data from that RPC. But instead of just trusting it, it checks it against the state route that it gets from the full nodes. And what we did in this project was basically implementing that part, which is how the light node talks to a full node and gets those updates. Yeah. And there are four endpoints. The first one, the bootstrap using the block route. You have the trusted block route in the network and you can just call the bootstrap on that block route and after that, yeah, you get a range of three updates, let's say three here, and when the light client has synced up to the latest block header, you can just keep calling optimistic update or finality update according to your needs. Yeah, so the project faces that we had was we got familiar with Prism and how light clients work. And then we started implementing the specs and then going back and forth with testing and debugging. This is nice, but this is a lie. This is how it actually is. So everything was weird. But, yeah, so the current state of the project is that we implemented the four RPC endpoints and we implemented that for like forks after alter, which is all the forks that support light clients. We implemented two databases, one for light client updates and one for light client bootstraps to store them and not have to manually compute them each time. And also we implemented saving updates and bootstrap when receiving new blocks. Unfortunately we haven't still implemented saving them while syncing. And also the P2P events and topics were implemented. So these functions are not only exposed through the beacon RPC, they are exposed through the P2P network as well. And these are all visible on the EPF Lite Client branch on Prism. Oh yeah, we have a, well, kind of demo. So these are old, but this is the Nimbus server, and this is our server. If we reload them at the same time, if we are lucky, we get the same result. Yeah, kind of the same result. And so the difference, as you can see, is that we have this bug which gives us three more execution branches, and we have to debug and see why. Yeah, but mainly we can see that this is just one of the RPC endpoints, but this is for the demo. They're mainly working correctly. Okay. Yeah. As of the next steps, we do have some work left. And the first of all would be we would need to test it out on a testnet. And, of course, like, measure the test performance and optimize it according to that. As also Bastian said before, like, we still don't save updates or bootstrap while syncing, which would be nice to have. So we do plan to add that too. And after that, yeah, adding like client stuff to E2A tests and code doses, yeah. That's for mainly for testing for all the forks. So that's what the next steps and yeah almost all consensus layers support like lines now including Nimbus, Loadstar. So yeah Prism is also into the game now. A special thanks to Radek and Josh and Mario for the cohort and Radek for the awesome mentoring here. Thank you Thank you very much Thank you very much guys. Yeah, I really appreciate you sharing all of this. Do we have any question for Bustin Rupam? Yeah Excuse me, I have to scream. Do you know if there's any plans to add endpoints to generate proofs? Sorry, add what? To add proofs. So, like the light line data set is very limited. There's proofs to prove the execution branch and the finalized header. But say you wanted to prove something else in the beacon state, like block roots. What would be super useful if there was an endpoint to say, I want to prove block roots at this index and just return the hash? I feel like that's super missing from the lifeline spec. So there are multiple EIPs open right now that work on adding, getting proofs from the execution clients, not the consensus clients. But yeah, there are multiple open PRs, I think at least four, that point to different parts of the block where you can get different proofs and then validate them using all these routes that are in the block header. Okay, but no beacon state proofs yet? Beacon state proofs? We have the state root hash in the block header. So if you have the proofs and if you have the data, you can check that against the state root. Yeah, but so what I mean is like, say you want to prove anything in the beacon state. At the moment, you need to download the whole beacon state as a Yeah, but so what I mean is like, say you want to prove anything in the beacon state, at the moment you need to download the whole beacon state is a Z, right? And then you have to like create the tree and then generate the proof ashes yourself. But like for instance, load star has an endpoint where you can say I want to prove this piece of the beacon state and then they just return the proof. That would be really cool if all the clients can add it because I think sometimes the apps using the light line data can't get to all the data that you'd actually need. For instance, I work on a bridge project and we need to prove, if you have a finalized header, that another header is an ancestor of that block. And you need the block roots proofs to do that. But it's missing from the light line data. Yeah, that is true. I don't think there is such a thing in Prism right now. But maybe... Hi, I'm from Prism. So, yeah, recently, actually, we had another person asking us the same question. So we're actively looking into that. So even if it's not in an official light client, like future plans for official specification, it's definitely another point I would like to add. So we can talk to Nimbus how they do that. And I think in the next few months, I hope we will have something to share with everyone. Awesome. That's great news. Thanks. Thank you so much, Radek. I just wanted to say thank you for this project. I had lost all hope of Prism ever supporting the Light Lion, so thank you. Awesome. Okay, quite a quick question. Maybe my understanding in proofs and stuff is quite limited, but can you, for example, bootstrap your light node from consensus client and then start to query the RPC provider for the latest data? So you would unload basically all the RPC calls from consensus clients? So you could use, if I'm understanding your question correctly, you're asking if you can, instead of asking the RPC providers for data, ask consensus node for data? No? Okay. asking the RPC providers for data, ask consensus node for data. No? Okay. The other way around. As I understood, you get the latest block data, like finalized... Block header. Latest block headers from the consensus node, yes. But can you do this from RPC clients? Well, yes, I think so. You can do that. But the point is that you basically check and verify all these updates one by one using the sync committee signature. So it doesn't really matter where you get those updates from as long as you have everyone in order from where you start. And this is all dependent on if your first trusted block route is actually part of the chain. So if you've been tricked to use something that's not on the chain and is on a fake chain, then you will keep up on that and you won't know what's wrong. But yeah, you can definitely get the updates from anywhere and just verify them one by one. Okay, awesome. Thank you so much, guys. Maybe one more question or comment or anything? Otherwise, yeah, huge thanks again. Thank you so much for all your work, all your contributions and the presentation. Thanks. Thank you very much.",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343c729dbb7a90e1adea32.vtt",
+ "transcript_text": " Thanks Mario. And so I'm Leah, software engineer, specialized in Rust and- You need to switch your slides here, yeah. Okay. Wait, wait, no, you need, yeah. Oh. Oh, but this thing- no, you need, yeah. Oh. No, you need to, I think I need to, not this. Oh, okay. I mean, I can duplicate otherwise. Okay. Amazing. Okay. Okay. Okay. Yeah. Thanks for being here. So I'm a software engineer specialized in Rust. And as Mario mentioned, this project was in fact supposed to be one week's maximum good first issue to start it in Lighthouse. And that's my initial project. So I'm very happy to be here. And I'm very happy to be here. And I'm very happy to be here. And I'm very supposed to be one week's maximum good first issue to start it in Lighthouse and not my initial project But as we are we are all developer and I think one of our defaults is like to underestimate developer time development time so Why so I pick this project of course to go deep into Lighthouse and understand better before transitioning to a more research project. But as a developer, I was interested in big refactor. So why does the team want to move between warp and axiom, but first what is warp and what are axiom? So there are web server framework, crates in Rust, and one has been developed a bit long time ago, so it's a bit low-level, low-level oriented, and a bit less easy to use, despite Axum has been developed by the Tokyo team, Tokyo organizations, and a bit easy to use, and why do they want to move? Of course they want to move for easier use, and because warp types, which is very focused",
"eventId": "devcon-7",
- "slot_start": 1731475800000,
- "slot_end": 1731476700000,
+ "slot_start": 1731474000000,
+ "slot_end": 1731474900000,
"slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1o1_9VdMiq5Uf_dyQTPf5R3mVbxhL4d0QI33ZiZNm28Q",
+ "resources_presentation": "https://docs.google.com/presentation/d/1xTcTdXk_Eq4KKe0Dg4IQWit5KLqwivJSom49AbKiMFM",
"resources_slides": null,
"speakers": [
- "bastin",
- "rupam"
+ "lea-narzis"
]
},
"vector": [
@@ -488104,11 +487092,9 @@
0,
0,
0,
- 6,
- 6,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -488409,7 +487395,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -488458,6 +487443,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -488708,7 +487694,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -488987,47 +487972,37 @@
},
{
"session": {
- "id": "lighthouse-introduction-to-siren",
- "sourceId": "F3ZPRJ",
- "title": "Lighthouse: Introduction to Siren",
- "description": "Sigma Prime would like to introduce Lighthouse's official user interface called Siren. Siren was made to monitor performance, display key metrics and help make lighthouse validator management easy. Siren comes with built in metrics, logging, and other features users will find useful when updating their validator.",
- "track": "Usability",
- "type": "Lightning Talk",
+ "id": "liquid-staking-for-daos",
+ "sourceId": "ZV39SQ",
+ "title": "Liquid Staking for DAOs",
+ "description": "DAOs face a critical challenge: aligning token holder interests with long-term success while maintaining effective governance. This talk explores the tension between governance participation and financial gains, as well as the dangers and opportunities posed by restaking protocols using DAO tokens. We'll examine how misaligned incentives can compromise DAOs and discuss innovative solutions like liquid staking and token splitting.",
+ "track": "Coordination",
+ "type": "Talk",
"expertise": "Beginner",
- "audience": "Stakers/Validators",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Home staking",
- "UI/UX",
- "Accessibility",
- "ui",
- "Accessibility",
- "Home staking",
- "UI/UX"
- ],
"keywords": [
- "lighthouse",
- "UI"
+ "DAOs"
+ ],
+ "tags": [
+ "Coordination",
+ "DAO",
+ "Best Practices",
+ "Mechanism design",
+ "Best Practices",
+ "Coordination",
+ "Mechanism design"
],
- "duration": 388,
"language": "en",
- "sources_swarmHash": "581e106f3b22dfacc1d56771706969f972348e514d3d6a94afc75aac47317df4",
- "sources_youtubeId": "RhlKmJqk0go",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673338d13a168eb535e44173.vtt",
- "transcript_text": " Good afternoon. I am Maverick. I am a Lighthouse engineer working at Sigma Prime. Lighthouse is a consistent client maintaining around 33% of the entire Ethereum network and today we want to introduce Siren. Before we get started I want to ask a couple of questions. Who here feels confident they can set up and configure a validator all on their own? Okay. Who here feels they would struggle to set up a validator, even if they had a video tutorial and a guide. Okay, if that's you, don't worry. It's okay. It's totally normal to feel like you're not technical enough to maintain a validator. As a matter of fact, Lighthouse has plenty of people that self-identify as noobs validating the network, and we always encourage them to participate and to ask questions when no prior knowledge required. And this is kind of the reason why we, what led us to make Insiren. We believe staking can be easy, accessible, and reliable. If an increase in home validators leads to more decentralization which increases Ethereum security then we must work hard to lower the technical barrier of entry preventing average users from committing to become validators. Okay so this is Siren. With this goal and user profile in mind we created a user interface that will help solo stakers at home. You can track validators, you can track statuses, log updates, and much more all in one location on our super sexy dashboard that comes in light and dark mode. With minimal configuration, Siren connects directly to your Lighthouse Validator client and your beacon node, allowing to communicate and consume data securely. Users have the option to install Siren via our Sigma Prime Docker containers or to download it and build it locally for some of our super users out there. Once activated, Siren allows you to manage your validators from any device on your home network or externally using an SSH or VPN access. So let's go over some features already out on Siren. It's super easy to track your value sync statuses, to get a breakdown of your total rewards, which includes ETH currency rates and earning estimates. You can get an aggregated value list that checks on the status the balance of aggregated of rewards and etc keep track of disk base CPU usage RAM usage on the machine that's running Lighthouse you can see how long your nodes have been running if you have warnings telling you if you're falling behind blocks, peer data. Some key more features are you can get notified of critical and error logs, which includes statistics on rates. You can monitor logs as they arrive in real time and use the search bar and find specific log data to copy and paste log information into the Discord if you need help. So what are some of the key actions? You can update your validator graffiti at the click of a button. For those OG validators with 00 withdrawal addresses, you can use SIREN to execute your BLS actions. And lastly, when you're ready, if you're ready to call it quits, in just a few steps, you can exit your validator safely and securely. All right, so what's next for Siren and what are we working on? Coming very, very soon, Siren will enable validated deposits. For those who already have a home validator, you may have used the Ethereum staking launchpad that create your validator. But through this, you are required to know the command line, you are required to make your own deposit JSON, your key stores, and import your validator into Lighthouse yourself. Now with Siren, there was supposed to be a video here, now withIREN you'll be able to take care of all of that on your own. SIREN condenses the entire flow into just a few steps, allowing full guidance and validation so you don't wreck yourself when you're moving 32 ETH. Hopefully soon 1 ETH when we reduce the fees down to 1 ETH. Okay, so we're preparing for the Pectra upgrade as well, EIP-7251. The upgrade will increase the max effective balance from 32 to 2048. This will enable validators to also consolidate. This will allow stakers to merge their validators together, which will help reduce operational overhead. And so Siren will enable this for all the Lighthouse users to be first in line in the consolidation queue the moment Pector goes live. And if you have any questions or you're interested, I'm going to reach out to the team. Just follow this and join us on Discord. We have a huge supportive community and a deaf team that will like to help out. This was made possible by the Sigma Prime team and that was it. It was lightning talk. I'm standing right behind you. We have one or two questions that I think we can handle in a minute. First question, what's best, light or dark mode? Dark mode. All right. This is rapid fire. Are there docs and how do I start using it? Yes, we do have docs. You can find them on the Lighthouse book. You just follow it and then there's a section for Siren itself.",
- "eventId": "devcon-7",
- "slot_start": 1731408000000,
- "slot_end": 1731408600000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1iWFucLqzajqGIcn5d4YFuRZ1zk1Y8VHURhoTiKQ1T-w",
- "resources_slides": null,
"speakers": [
- "ricki-moore"
- ]
+ "dennison-bertram"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731394800000,
+ "slot_end": 1731396600000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1o6QVDTmx3Wki_7YsSzzIkIb_lvDouMYuQyMpQ98lqww"
},
"vector": [
0,
@@ -489038,13 +488013,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -489484,11 +488456,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -489789,6 +488761,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -489812,6 +488785,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -489841,8 +488815,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -489868,7 +488840,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -489884,6 +488855,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -489937,6 +488909,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -490189,7 +489162,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -490352,7 +489324,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -490360,48 +489331,31 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "lighthouse-transition-journey-from-warp-to-axum",
- "sourceId": "ZF79GZ",
- "title": "Lighthouse transition journey : from warp to axum",
- "description": "This talk will explore how to approach a significant refactor of the HTTP framework for lighthouse. \r\n\r\nIt will cover:\r\n- Measuring the performance of endpoints between Warp and Axum\r\n- A concrete plan for implementing the necessary changes",
- "track": "[CLS] EPF Day",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
+ "id": "liron-achdut",
+ "sourceId": "TPPWYB",
+ "title": "Liron Achdut",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Developer Infrastructure",
- "Light Clients"
- ],
- "keywords": [
- "Performance",
- "Developer",
- "experience"
- ],
- "duration": 537,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "0ba36082c0dc4df92f95f85927da7080d528c36d541326d01a2f2c36606c619e",
- "sources_youtubeId": "aIYhDRmoMdE",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343c729dbb7a90e1adea32.vtt",
- "transcript_text": " Thanks Mario. And so I'm Leah, software engineer, specialized in Rust and- You need to switch your slides here, yeah. Okay. Wait, wait, no, you need, yeah. Oh. Oh, but this thing- no, you need, yeah. Oh. No, you need to, I think I need to, not this. Oh, okay. I mean, I can duplicate otherwise. Okay. Amazing. Okay. Okay. Okay. Yeah. Thanks for being here. So I'm a software engineer specialized in Rust. And as Mario mentioned, this project was in fact supposed to be one week's maximum good first issue to start it in Lighthouse. And that's my initial project. So I'm very happy to be here. And I'm very happy to be here. And I'm very happy to be here. And I'm very supposed to be one week's maximum good first issue to start it in Lighthouse and not my initial project But as we are we are all developer and I think one of our defaults is like to underestimate developer time development time so Why so I pick this project of course to go deep into Lighthouse and understand better before transitioning to a more research project. But as a developer, I was interested in big refactor. So why does the team want to move between warp and axiom, but first what is warp and what are axiom? So there are web server framework, crates in Rust, and one has been developed a bit long time ago, so it's a bit low-level, low-level oriented, and a bit less easy to use, despite Axum has been developed by the Tokyo team, Tokyo organizations, and a bit easy to use, and why do they want to move? Of course they want to move for easier use, and because warp types, which is very focused",
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731474000000,
- "slot_end": 1731474900000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1xTcTdXk_Eq4KKe0Dg4IQWit5KLqwivJSom49AbKiMFM",
- "resources_slides": null,
- "speakers": [
- "lea-narzis"
- ]
+ "slot_start": 1731654000000,
+ "slot_end": 1731657600000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1YdbQcP_NmrA5hsp8UnCOjPl-Em8SCjy8qlYVJjrw3jo"
},
"vector": [
0,
@@ -490413,13 +489367,13 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -490859,7 +489813,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -491176,7 +490129,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -491210,7 +490162,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -491717,8 +490668,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
2,
@@ -491739,37 +490690,35 @@
},
{
"session": {
- "id": "liquid-staking-for-daos",
- "sourceId": "ZV39SQ",
- "title": "Liquid Staking for DAOs",
- "description": "DAOs face a critical challenge: aligning token holder interests with long-term success while maintaining effective governance. This talk explores the tension between governance participation and financial gains, as well as the dangers and opportunities posed by restaking protocols using DAO tokens. We'll examine how misaligned incentives can compromise DAOs and discuss innovative solutions like liquid staking and token splitting.",
- "track": "Coordination",
+ "id": "little-things-weve-learned-about-fhe",
+ "sourceId": "9JFDZA",
+ "title": "Little Things We've learned About FHE",
+ "description": "Recently, at PSE, we have been exploring the field of cryptography, specifically focusing on Fully Homomorphic Encryption (FHE). FHE enables secure interactions with encrypted data between different parties.\r\n\r\nIn this presentation, we will introduce key concepts and essential information tailored for developers and application designers. This will help them quickly grasp the fundamentals without getting bogged down by complex mathematical details.",
+ "track": "Applied Cryptography",
"type": "Talk",
- "expertise": "Beginner",
- "audience": "Community",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "DAOs"
+ "ELI5"
],
"tags": [
- "Coordination",
- "DAO",
- "Best Practices",
- "Mechanism design",
- "Best Practices",
- "Coordination",
- "Mechanism design"
+ "Cryptography",
+ "Homomorphic Encryption",
+ "eli5",
+ "Cryptography",
+ "Homomorphic Encryption"
],
"language": "en",
"speakers": [
- "dennison-bertram"
+ "chih-cheng-liang"
],
"eventId": "devcon-7",
- "slot_start": 1731394800000,
- "slot_end": 1731396600000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1o6QVDTmx3Wki_7YsSzzIkIb_lvDouMYuQyMpQ98lqww"
+ "slot_start": 1731574800000,
+ "slot_end": 1731576600000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1yFyLyjYjdDzT6MDPS4LGolPm0BsYYfhsoxLz5fezE_k"
},
"vector": [
0,
@@ -491782,7 +490731,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -492228,8 +491176,8 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -492531,11 +491479,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -492555,7 +491503,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -492613,6 +491560,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -492625,7 +491573,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -492679,7 +491626,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -492931,6 +491877,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -493084,6 +492031,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -493094,8 +492042,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -493107,25 +492053,27 @@
},
{
"session": {
- "id": "liron-achdut",
- "sourceId": "TPPWYB",
- "title": "Liron Achdut",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "id": "live-music-open-jam-or-something-in-between",
+ "sourceId": "FVHR9Y",
+ "title": "Live Music, Open Jam, Or Something In Between",
+ "description": "This will be an open, emergent, co-created format where we're inviting everyone to make music together.",
"track": "Entertainment",
"type": "Music",
- "expertise": "",
- "audience": "Engineering",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [],
"tags": [],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "marc-nitzsche"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731654000000,
- "slot_end": 1731657600000,
+ "slot_start": 1731477600000,
+ "slot_end": 1731481200000,
"slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1YdbQcP_NmrA5hsp8UnCOjPl-Em8SCjy8qlYVJjrw3jo"
+ "resources_presentation": "https://docs.google.com/presentation/d/1CYvsKADAZ5-gmioFl_lFIeEXHIyeSBbn2GOtenPyFq4"
},
"vector": [
0,
@@ -493585,11 +492533,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 6,
0,
0,
0,
@@ -494445,13 +493389,14 @@
2,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -494463,35 +493408,40 @@
},
{
"session": {
- "id": "little-things-weve-learned-about-fhe",
- "sourceId": "9JFDZA",
- "title": "Little Things We've learned About FHE",
- "description": "Recently, at PSE, we have been exploring the field of cryptography, specifically focusing on Fully Homomorphic Encryption (FHE). FHE enables secure interactions with encrypted data between different parties.\r\n\r\nIn this presentation, we will introduce key concepts and essential information tailored for developers and application designers. This will help them quickly grasp the fundamentals without getting bogged down by complex mathematical details.",
- "track": "Applied Cryptography",
- "type": "Talk",
+ "id": "local-build-why-language-is-key-to-decentralization",
+ "sourceId": "UHVBNL",
+ "title": "Local Build: Why language is key to decentralization",
+ "description": "Localization is not a “nice to have” for decentralization: it is a core requirement.\r\n\r\nOver 50% of ETH nodes are between the US and Germany. 90% of stablecoins are USD-pegged. The world we’re creating is stifled by the one that already exists. \r\n\r\nTo be credibly decentralized, Ethereum must be built and secured in the human languages of people outside of the current paradigm. This talk will highlight web3-native problems and tangible solutions in l10n, from the technical to the organizational.",
+ "track": "Coordination",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
"keywords": [
- "ELI5"
+ "Internationalization",
+ "Localization"
],
"tags": [
- "Cryptography",
- "Homomorphic Encryption",
- "eli5",
- "Cryptography",
- "Homomorphic Encryption"
+ "Decentralization Improvements",
+ "Languages",
+ "User Experience",
+ "localization",
+ "l10n",
+ "Decentralization Improvements",
+ "Languages",
+ "User Experience"
],
"language": "en",
"speakers": [
- "chih-cheng-liang"
+ "oliver-jl-renwick",
+ "laurel"
],
"eventId": "devcon-7",
- "slot_start": 1731574800000,
- "slot_end": 1731576600000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1yFyLyjYjdDzT6MDPS4LGolPm0BsYYfhsoxLz5fezE_k"
+ "slot_start": 1731490800000,
+ "slot_end": 1731491400000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1zMgBNNs4mjcJlQvsWzcG-01qBLosEtl3W_zPUteNz-0"
},
"vector": [
0,
@@ -494504,6 +493454,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -494952,6 +493903,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -495247,9 +494199,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
+ 6,
0,
0,
0,
@@ -495336,14 +494286,11 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -495655,7 +494602,7 @@
0,
0,
2,
- 0,
+ 2,
0,
0,
0,
@@ -495811,11 +494758,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -495829,33 +494776,41 @@
},
{
"session": {
- "id": "live-music-open-jam-or-something-in-between",
- "sourceId": "FVHR9Y",
- "title": "Live Music, Open Jam, Or Something In Between",
- "description": "This will be an open, emergent, co-created format where we're inviting everyone to make music together.",
- "track": "Entertainment",
- "type": "Music",
+ "id": "logs-for-you-anon",
+ "sourceId": "RRYVNW",
+ "title": "Logs for you anon",
+ "description": "The removal of log events has sparked a discussion about its implications for apps that rely on events to display information. Without logs, developers would need to use specialized software to index the chain and search for specific actions, which is costly, not friendly with privacy and requires a case-by-case approach. This is in contrast to the current system, where logs provide developers with the freedom to query the chain anonymously, without limits, and without sacrificing any detail.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "logs",
+ "local apps",
+ "indexing"
+ ],
+ "tags": [
+ "DevEx",
+ "Privacy",
+ "Decentralization",
+ "indexing",
+ "Decentralization",
+ "DevEx",
+ "Privacy"
+ ],
"language": "en",
"speakers": [
- "marc-nitzsche"
+ "yabir-garcia-benchakhtir"
],
"eventId": "devcon-7",
- "slot_start": 1731477600000,
- "slot_end": 1731481200000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1CYvsKADAZ5-gmioFl_lFIeEXHIyeSBbn2GOtenPyFq4"
+ "slot_start": 1731646200000,
+ "slot_end": 1731646800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/19tr5hJbHHcDFcMqxEDdnvWaK2uCU2yR2HV12bhQ1NTQ"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -496310,16 +495265,13 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -496638,6 +495590,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -496709,6 +495662,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -496722,6 +495676,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -497015,6 +495970,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -497169,12 +496125,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -497187,40 +496143,53 @@
},
{
"session": {
- "id": "liveops-for-autonomous-worlds",
- "sourceId": "DGU8PN",
- "title": "Liveops for autonomous worlds",
- "description": "How do you keep a world alive, especially one that is deliberately ownerless and autonomous?\r\n\r\nAs creators and stewards of a world, how should you react and not react to certain events unfolding in the world? \r\n\r\nWe will share our experience and learnings from running This Cursed Machine and previous projects.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Talk",
- "expertise": "Beginner",
+ "id": "long-term-decentralized-storage-for-blobs",
+ "sourceId": "RCVFHX",
+ "title": "Long-term Decentralized Storage for Blobs",
+ "description": "This talk will present a possible scheme to store blobs and other historical data for the long-term in a decentralized fashion. The technology relies on erasure codes and SNARKs. This talk is related to EIP-4444.",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
"audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [],
"tags": [
- "Gaming",
- "Autonomous World",
- "Autonomous World",
- "Gaming"
+ "Core Protocol",
+ "Blobs",
+ "Sustainability",
+ "storage",
+ "Blobs",
+ "Core Protocol",
+ "Sustainability"
],
- "language": "en",
- "speakers": [
- "arthur-roing-baer",
- "alex-declino",
- "rasmus-svensson"
+ "keywords": [
+ "Storage"
],
+ "duration": 324,
+ "language": "en",
+ "sources_swarmHash": "146236064ab2f260f965665a61e0db66f86769d420f93b351c716f64d8f6e2bf",
+ "sources_youtubeId": "Bizi9n0t6pY",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343a969dbb7a90e19386fb.vtt",
+ "transcript_text": " Thank you. So, good morning, everyone. Thank you for being here. I'm Leo. I'm a researcher with Codex and also from Megalabs. And today, I'm going to talk about decentralized structure for blobs. Actually, it's very nice that we have this talk by Yannick taking us through time. And now I'm going to take you through space. So this is, yeah, the timeline of the Ethereum history. So we have the genesis block that occurred in July 30 of 2015. Then we had the merge about seven years later happening in 2022. During that time, we had something in the order of 15.5 million blocks. And if you put all of those together, that takes about 427 gigabytes of space. Then in March 2024, we had the blobs, the beginning of the blobs, the EIP-4844. And so between these two dates, we had the blobs, the beginning of the blobs, the EIP-4844. And so between these two dates, we had something in the order of 3 point something million blocks. And then since March until now, so about seven months ago, we have been generating blocks with blobs all the time. And in these last seven months, we have generated more data than in the first seven years of Ethereum. So that's quite a significant amount of data. And to store the entire history of Ethereum right now, it takes about one terabyte. So basically what I'm trying to say today, if there is something that should remain in your head from this talk, is that storing the entire Ethereum history in every single node of the network is kind of unsustainable. And there are several things that are being developed. So one is the portal network, but there is also other ideas, and I want to show one of those in this talk. So there are some files that have been proposed that are called era files. An era file is a file that stores about exactly 8,192 blocks, the state, and also some index data. Basically, one era file is about 27 hours, and it takes between 500 and 600 megabytes of space. So this format has been proposed by Jacek from the IFT. And the PandaOps team, specifically Pari, took all that data from the pre-merge, so it's about 15.5 million blocks, and put it on BitTorrent. So this is the size of the data during those first seven years. Please notice that the blocks are between 50 to 100 kilobytes toward the end of that period. Now, if you look between what happens after the merge, the size of the block starts increasing significantly. We reach almost 200 kilobytes in average for the blocks. So during that time, we have about almost 4 million blocks. And if you take all those blocks together, that is about 98 gigabytes of data. And there has been this proposal again by the PandaOps team to create like a beacon chain checkpoint sync endpoint where you can actually checkpoint sync your client directly from off-network sources. So you don't need to get all the blocks from the peer-to-peer network. You get all the blocks from a specific off-chain, off-network source. And now if you look at the blocks after the blobs, basically, there is a new proposal now. It's called the ERB files, which are specifically for storing blobs. And there is no state on those files, but there is a KCG commitment included as well. You can see that during this time the size of the blocks have decreased because now we are going down to almost 50 kilobytes in size. So this is again a proposal by the Nimbus team and I think this is a great idea. And what we are trying to do now in Codex is to store this history from Ethereum in Codex. So Codex is a decentralized storage that is protected with the ratio coding, with very reliable CK technology, and we are storing the entire history of Ethereum in Code in codec so that's basically all I wanted to present today and if you are interested well you can come to talk to us offline or in the Nimbus booth as well thank you thank you question time I love this part of the session question time so who's going first oh wow no question for Dr. Leonardo? Oh, wow. You're a good teacher. Are you a professor? Sorry? Are you a professor? I work at the university, yes. Oh, no wonder. So your students are saying no question for you, right? Oh, one question. Who? Can I see you? Who? Who is good? Ask. No question? Who? Can I see you? Who? Who is going to ask? No question? No question. Okay, so, doctor, it seems you gave such an awesome presentation. And what do you tell Dr. Leonardo? Doctor, thank you. Help me. Welcome, and say thank you to Dr. Leonardo.",
"eventId": "devcon-7",
- "slot_start": 1731579300000,
- "slot_end": 1731580800000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1cRzLs04mUfuekdXDjeGyK1tj6bJ6L74N8aZzY2trYpk"
+ "slot_start": 1731469800000,
+ "slot_end": 1731470400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/19uBY8dZebCAmZtuh27GvgwcgDo7WY_BpHnT84sKBL6M",
+ "resources_slides": null,
+ "speakers": [
+ "leo-bautista-gomez"
+ ]
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -497229,9 +496198,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -497676,13 +496642,11 @@
0,
0,
0,
- 6,
- 6,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -497989,6 +496953,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -498033,6 +496998,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -498079,9 +497045,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
0,
0,
0,
@@ -498320,6 +497283,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -498381,6 +497345,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -498530,9 +497495,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -498552,40 +497517,37 @@
},
{
"session": {
- "id": "local-build-why-language-is-key-to-decentralization",
- "sourceId": "UHVBNL",
- "title": "Local Build: Why language is key to decentralization",
- "description": "Localization is not a “nice to have” for decentralization: it is a core requirement.\r\n\r\nOver 50% of ETH nodes are between the US and Germany. 90% of stablecoins are USD-pegged. The world we’re creating is stifled by the one that already exists. \r\n\r\nTo be credibly decentralized, Ethereum must be built and secured in the human languages of people outside of the current paradigm. This talk will highlight web3-native problems and tangible solutions in l10n, from the technical to the organizational.",
- "track": "Coordination",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Product",
- "featured": false,
+ "id": "lunarpunk-endgame",
+ "sourceId": "EVHFWA",
+ "title": "Lunarpunk Endgame",
+ "description": "Global surveillance is a static world where change is surpressed and society cannot evolve. In contrast, an anonymity-enhanced world resembles a forest. New civilizational experiments blossom like flowers, radiating outward from the freedom-fighters of the future.\r\n\r\nThe lunarpunk end game is to enable a new ecology of social orders. This talk will describe the grand vision of lunarpunk: multipolar space-faring civilization, human speciation, and the reproduction life throughout the cosmos.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Engineering",
+ "featured": true,
"doNotRecord": false,
"keywords": [
- "Internationalization",
- "Localization"
+ "Lunarpunk"
],
"tags": [
- "Decentralization Improvements",
- "Languages",
- "User Experience",
- "localization",
- "l10n",
- "Decentralization Improvements",
- "Languages",
- "User Experience"
+ "Network State",
+ "Anonymity",
+ "Autonomous World",
+ "lunarpunk",
+ "Anonymity",
+ "Autonomous World",
+ "Network State"
],
"language": "en",
"speakers": [
- "oliver-jl-renwick",
- "laurel"
+ "rachel-rose-oleary"
],
"eventId": "devcon-7",
- "slot_start": 1731490800000,
- "slot_end": 1731491400000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1zMgBNNs4mjcJlQvsWzcG-01qBLosEtl3W_zPUteNz-0"
+ "slot_start": 1731488400000,
+ "slot_end": 1731490200000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1pdPYWGnlJDvugH2zzLYqzKQrvDlutN5EGd8EBIpbeR4"
},
"vector": [
0,
@@ -498593,13 +497555,13 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -499051,7 +498013,6 @@
0,
0,
6,
- 6,
0,
0,
0,
@@ -499346,7 +498307,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -499356,7 +498316,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -499366,6 +498325,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -499385,6 +498346,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -499437,7 +498399,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -499448,6 +498409,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -499750,7 +498712,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -499903,15 +498864,13 @@
0,
2,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -499923,39 +498882,47 @@
},
{
"session": {
- "id": "logs-for-you-anon",
- "sourceId": "RRYVNW",
- "title": "Logs for you anon",
- "description": "The removal of log events has sparked a discussion about its implications for apps that rely on events to display information. Without logs, developers would need to use specialized software to index the chain and search for specific actions, which is costly, not friendly with privacy and requires a case-by-case approach. This is in contrast to the current system, where logs provide developers with the freedom to query the chain anonymously, without limits, and without sacrificing any detail.",
- "track": "Cypherpunk & Privacy",
+ "id": "maci-why-do-we-need-private-voting-and-what-are-we-up-to",
+ "sourceId": "TCJJW3",
+ "title": "MACI - Why do we need private voting and what are we up to",
+ "description": "MACI is a protocol that can be used to run private on chain polls. This talk will introduce the protocol, dive into some of the technical aspects. Finally we will talk about the team's plans for the future and how the community can get involved to help improve the project.",
+ "track": "Applied Cryptography",
"type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "logs",
- "local apps",
- "indexing"
- ],
"tags": [
- "DevEx",
+ "Coordination",
+ "Quadratic Voting",
+ "Public good",
+ "voting",
+ "Coordination",
+ "Public good",
+ "Quadratic Voting"
+ ],
+ "keywords": [
"Privacy",
- "Decentralization",
- "indexing",
- "Decentralization",
- "DevEx",
- "Privacy"
+ "Voting"
],
+ "duration": 606,
"language": "en",
- "speakers": [
- "yabir-garcia-benchakhtir"
- ],
+ "sources_swarmHash": "3e12944268e30652d72b931cdbdd1bf68e19741b4d3f57dd9daf2464127f2dd6",
+ "sources_youtubeId": "18KFAia72Ww",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732ffcf80d989c5b7b957f9.vtt",
+ "transcript_text": " yeah just works works yes I work at PC we do a lot of program of photography cool stuff comes to us we have a booth there yeah this is Macy in five minutes and my private what is important just an agenda will talk through what is Macy in five minutes and why private voting is important. Just an agenda. We'll talk through what is Macy, why do we need it, how it works, and just look into the future. So Macy stands for Minimal Anti-Collusion Infrastructure. And in a nutshell, it's a protocol that allows to run private on-chain voting. These are some of the properties that we try to push. So collusion resistance is increased because there's only one entity which can be certain of the validity of the vote. If that is trusted, then things get a little bit all the votes are encrypted. You can also, you can edit a vote by newly finding it, but whatever is set on chain must be processed. And even if we talk about this trusted entity, a coordinator, even if they are malicious, they cannot really produce any false output of the vote. So why do we need this? I mean, I think voting is a very sensible topic. Bribery and collusions happens everywhere. And I think something that a lot of people find very close to. And it's great to work on this for that reason. But yeah, like, let's take an example, like, which are the funding or voting, where more people coming together can actually make a difference. But if it's easy to collude, then the results can be gained. And also think, like, if you know how people vote, then you can also be conditioned. Like, there's some people just don't want to spend some time going through the candidates or whatever you're voting for. And you see like a famous person, oh, cool, I voted for this. Why don't I just do it? But if you don't really know, they cannot prove to you that that's actually their valid vote, then you could just maybe think for yourself. And then bribery is reduced because it's hard to prove and it's hard to collude. And our goal is to make voting more democratic and fair. So in a nutshell, the architecture, the smart contracts that work on any EVM chain, there's some circum circuits that can be used, are used to prove that all the votes sent are valid or invalid. And the tally circuit, which tallies all the votes. So this is a run by this trusted entity, the coordinator, and all the results are posted on chain for everyone to verify. Yeah, there's some SDKs and TypeScript stuff if people want to integrate it. Hopefully you do. And yeah, how does it work? As a user flow, you come and register into the platform. You register with your Macy key, which is not to be confused with your Ethereum key. You can just prove you're human, prove you own a Zupas ticket, and then you register into the system. Then you can send encrypted votes that only the coordinator is able to decrypt. And you also sign them with this Macy private key, so no one else can send votes on your behalf. And then as a user, after the coordinator processes everything, you want to verify that everything was done correctly. The votes are encrypted using a CDA, so there's a share key between you and the coordinator. It is signed, and in the vote, you specify who you're voting for, whether it's like a yes or no vote, or like you're giving some sort of weight in which you're voting. And yeah, that's encrypted, send on chain, fully encrypted, and you also send a public key that you used to generate the share key so the coordinator can just reverse the process. To finalize, the coordinator just takes all of the votes and just all the events from these smart contracts and then just generates the secret proofs using the circuits that we talked about, and they'll just post them on chain. They cannot censor any vote, they cannot prove something that is not happened, so that's some of the cool stuff about it. And yeah, looking into the future, what we try to do is to make it easier for people to use and actually get someone to use it. Some of the research topics that we have planned is to actually decentralize this coordinator figure using MPC and try and make it even more harder to collude. There might be some time to also look into new voting mechanisms, or like funding mechanisms that could be integrated. And maybe we'll also be thinking how to rethink the architecture and kind of integrate it with a lot of other PSE protocol, like Semaphore, R&R, and Exuvia. Okay, so we are running a DEF CON QV round. There's like 250K put by the impact teams at DEF CON. So you can go and vote. You can try Macy. You just need to prove you're an attendee by using Zupas. This is what it looks like. Just try it out. Just be gentle, because, yeah, just be gentle with this app. Don't break it looks like. Just try it out. Just be gentle, because yeah, just be gentle with this app. Don't break it, please. But yeah, that's just showcase how Macie work. And yeah, that's it. Five minutes. Thank you, Alessandro. Questions? Do you want to try this one for me? Thanks. Sorry, dude. You mentioned at one point that there was a proof of humanity required for the voting. How do we achieve that without relying on a centralized entity? And also, how do you protect against civil attacks in your voting chain? Yeah, that's a good question. So to prevent civil attacks, we have this concept of gatekeepers. So you need to prove that's fully customizable. So whoever runs the vote will say, hey, I'm only accepting someone that approves. It's a DEF CON, so by scanning a ticket or, like, on something like an NFT and other things. So that's how we put it against Sibyls. So Macy's is only as good as the Sibyls solution that you decide to use. And for the trusted assumption is that this coordinated figure could be removed with the NPC. So you have, like like a collaborative snark. I mean, I'm not really good into this stuff. So at a high level, just like instead of having one coordinator, you have multiple and there might be some sort of consensus, some sort of way of, how to say, to make it hard for them to also not post the results and not collude between themselves. But yeah, that's probably where we're going. And some smart people in PSC that already thought how Macy would look with MPC. So hopefully we'll be able to implement that very soon. I think we have a question at the back there. In the beginning, the receipt, receipt freeness of the vote and that it's impossible to show who you voted for. But what if the user would simply share their private keys and then reveal everything that they did, they would still be able to prove the vote in that situation. Yeah, that's a good point. So the thing is, like, when you cast a vote, you can nullify it. So I show you, hey, I voted for this, but then you couldn't trust me that I actually did, unless the coordinator colludes with this other entity. And yeah, one of the other issues is if you give out your key, then they will be able to post votes on your behalf. So it's up to the user to not sell the key. Yeah, that would kind of mess up with the system as well. And hopefully we'll be able to find some good solution for that. Yeah. I think there's a system called something with bear vote, like the animal that has a property like you need an additional salt to prove that it was actually you. And if you provide a wrong salt in the proving process, the result comes off of somebody else's vote. Okay, I'm not familiar with this, to be honest. But yeah, if you just hit me up later and just describe this, that'd be interesting to talk about. Any other questions? Yeah, I have some questions. There is any possibility you have a credential for get about your knowledge, for example, you know computer science and there is a proposal for some upgrade in the system. There is any possibility to do this? So like to automate, some sort of execution after the tile is produced? Yeah, the proposal is made, you get a vote, and the calculation of your knowledge is the quadratic voting. And then there's some sort of action that happens after? Like, that's what you mean, like, in, let's say, DAO governance or something? Yeah. Yeah, okay. That's not something we explore yet, DAO governance. Actually, I talked to a lot of people about it today. So, yeah, that's still possible. It's the tallies posted on-chain, so they can be automated as a hook. After the tally is fully approved, on-chain is the data, something can happen. That's totally doable, yeah. Yeah, thank you.",
"eventId": "devcon-7",
- "slot_start": 1731646200000,
- "slot_end": 1731646800000,
+ "slot_start": 1731394800000,
+ "slot_end": 1731395400000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/19tr5hJbHHcDFcMqxEDdnvWaK2uCU2yR2HV12bhQ1NTQ"
+ "resources_presentation": "https://docs.google.com/presentation/d/1paq5inxTY__nUEseJKES2bwcdoZZSvs-h5ZpEXOfwsg",
+ "resources_slides": null,
+ "speakers": [
+ "ctrlc03"
+ ]
},
"vector": [
0,
@@ -499963,13 +498930,12 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -500740,8 +499706,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -500812,7 +499776,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -500820,13 +499783,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -500866,6 +499829,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -500919,6 +499883,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -501069,6 +500034,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -501121,8 +500087,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -501293,45 +500257,47 @@
},
{
"session": {
- "id": "long-term-decentralized-storage-for-blobs",
- "sourceId": "RCVFHX",
- "title": "Long-term Decentralized Storage for Blobs",
- "description": "This talk will present a possible scheme to store blobs and other historical data for the long-term in a decentralized fashion. The technology relies on erasure codes and SNARKs. This talk is related to EIP-4444.",
- "track": "Core Protocol",
+ "id": "making-defensive-technology-offensive-how-to-get-cypherpunk-ideals-to-the-masses",
+ "sourceId": "RGMXQ7",
+ "title": "Making defensive technology offensive: How to get cypherpunk ideals to the masses",
+ "description": "Cryptography is an inherently defensive tool; it hides your information from adversaries. This is crucial to prevent censorship or monitoring of your data. But it's often sold to consumers with fearmongering about all-powerful malicious actors, which is often ignored by all except the privacy-conscious. We explore real-life examples of offensive cryptographic affordances like interoperability, efficiency, and user consent as stronger motivations for the masses to migrate to cypherpunk tech.",
+ "track": "Cypherpunk & Privacy",
"type": "Lightning Talk",
- "expertise": "Intermediate",
+ "expertise": "Beginner",
"audience": "Product",
"featured": false,
"doNotRecord": false,
"tags": [
- "Core Protocol",
- "Blobs",
- "Sustainability",
- "storage",
- "Blobs",
- "Core Protocol",
- "Sustainability"
+ "Frameworks",
+ "Values",
+ "Use cases of cryptography",
+ "messaging",
+ "Frameworks",
+ "Use cases of cryptography",
+ "Values"
],
"keywords": [
- "Storage"
+ "d/acc",
+ "adoption",
+ "messaging"
],
- "duration": 324,
+ "duration": 352,
"language": "en",
- "sources_swarmHash": "146236064ab2f260f965665a61e0db66f86769d420f93b351c716f64d8f6e2bf",
- "sources_youtubeId": "Bizi9n0t6pY",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "W5bRYUO-Wk8",
"sources_ipfsHash": "",
"sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343a969dbb7a90e19386fb.vtt",
- "transcript_text": " Thank you. So, good morning, everyone. Thank you for being here. I'm Leo. I'm a researcher with Codex and also from Megalabs. And today, I'm going to talk about decentralized structure for blobs. Actually, it's very nice that we have this talk by Yannick taking us through time. And now I'm going to take you through space. So this is, yeah, the timeline of the Ethereum history. So we have the genesis block that occurred in July 30 of 2015. Then we had the merge about seven years later happening in 2022. During that time, we had something in the order of 15.5 million blocks. And if you put all of those together, that takes about 427 gigabytes of space. Then in March 2024, we had the blobs, the beginning of the blobs, the EIP-4844. And so between these two dates, we had the blobs, the beginning of the blobs, the EIP-4844. And so between these two dates, we had something in the order of 3 point something million blocks. And then since March until now, so about seven months ago, we have been generating blocks with blobs all the time. And in these last seven months, we have generated more data than in the first seven years of Ethereum. So that's quite a significant amount of data. And to store the entire history of Ethereum right now, it takes about one terabyte. So basically what I'm trying to say today, if there is something that should remain in your head from this talk, is that storing the entire Ethereum history in every single node of the network is kind of unsustainable. And there are several things that are being developed. So one is the portal network, but there is also other ideas, and I want to show one of those in this talk. So there are some files that have been proposed that are called era files. An era file is a file that stores about exactly 8,192 blocks, the state, and also some index data. Basically, one era file is about 27 hours, and it takes between 500 and 600 megabytes of space. So this format has been proposed by Jacek from the IFT. And the PandaOps team, specifically Pari, took all that data from the pre-merge, so it's about 15.5 million blocks, and put it on BitTorrent. So this is the size of the data during those first seven years. Please notice that the blocks are between 50 to 100 kilobytes toward the end of that period. Now, if you look between what happens after the merge, the size of the block starts increasing significantly. We reach almost 200 kilobytes in average for the blocks. So during that time, we have about almost 4 million blocks. And if you take all those blocks together, that is about 98 gigabytes of data. And there has been this proposal again by the PandaOps team to create like a beacon chain checkpoint sync endpoint where you can actually checkpoint sync your client directly from off-network sources. So you don't need to get all the blocks from the peer-to-peer network. You get all the blocks from a specific off-chain, off-network source. And now if you look at the blocks after the blobs, basically, there is a new proposal now. It's called the ERB files, which are specifically for storing blobs. And there is no state on those files, but there is a KCG commitment included as well. You can see that during this time the size of the blocks have decreased because now we are going down to almost 50 kilobytes in size. So this is again a proposal by the Nimbus team and I think this is a great idea. And what we are trying to do now in Codex is to store this history from Ethereum in Codex. So Codex is a decentralized storage that is protected with the ratio coding, with very reliable CK technology, and we are storing the entire history of Ethereum in Code in codec so that's basically all I wanted to present today and if you are interested well you can come to talk to us offline or in the Nimbus booth as well thank you thank you question time I love this part of the session question time so who's going first oh wow no question for Dr. Leonardo? Oh, wow. You're a good teacher. Are you a professor? Sorry? Are you a professor? I work at the university, yes. Oh, no wonder. So your students are saying no question for you, right? Oh, one question. Who? Can I see you? Who? Who is good? Ask. No question? Who? Can I see you? Who? Who is going to ask? No question? No question. Okay, so, doctor, it seems you gave such an awesome presentation. And what do you tell Dr. Leonardo? Doctor, thank you. Help me. Welcome, and say thank you to Dr. Leonardo.",
+ "sources_streamethId": "6734a08f9dbb7a90e1469361",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734a08f9dbb7a90e1469361.vtt",
+ "transcript_text": " Cool. Hi, guys. So my talk is going to be about basically, like, focused on cryptography as defensive technology, because that's my area of expertise, how we can take various cryptographic tools that are super powerful and try to find ways to be clear this is more like encryption signatures EAPs this sort of thing obviously under the umbrella of like DIAQ and defensive technologies there's lots of other stuff going on and I think how I would personally define cryptography is that it's the art of making things hard to break in this definition it is like very inherently a defensive technology you're literally trying to make tools that is very difficult for adversaries to forge or break into or otherwise sort of damage the integrity of. And I want to look at just a very small set of examples here. This is not comprehensive at all, but at one really prominent use case of privacy-preserving technologies in the wild, which is VPNs. And VPNs, I think if any of you guys have been to, like, New York or Chicago or a couple other major American cities, you might have seen these, like, Mulvad VPN ads everywhere. For context, I personally use Mulvad, so this is not really a dig at them, but a lot of their ads are very sort of, like, a bit of both, like, hopeful, but also kind of, like, fear-mongery, and I honestly am not sure how successful this has been for them. I definitely know for myself, like, I got Mulvad before these ads came on, and, like, when I do see them in, like, the subway, in the train, I'm, like, I always think, like, is this, like, do people want to see this sort of thing? And, like, one reference point in my mind that I have is NordVPN, a lot of these other VPNs, this is not actually an ad from them, to be very clear, but if you're a big YouTube user, you know that Nord and Express, these sort of VPN companies, are major funders of every YouTuber. And it's really interesting to see how that marketing has changed over the past few years. I feel like initially it was very much focused on, oh, this will protect you from your internet provider seeing your history. And often that's still mentioned, but actually most of the time now, the emphasis of the ad reel is always on you can watch Netflix in other countries. You can do this new, you have this new affordance from using this VPN. And it's always kind of what they talk about for a little bit longer. And I feel like it is a very good representation of the fact that I think users will generally respond to things that are value adds and not purely sort of defensive measures against some sort of threat. And to be clear, I'm very much a cypherpunk, and I deeply believe in this technology. But at the same time, I also believe that if we're not able to do this sort of communication work, we're not going to be able to get users the defense and safety that they deserve. And so I want to talk through just a few different kind of like high level affordances that I think are worth leaning into and talking about more. The first is the idea that privacy is really ownership. And I think ownership is something that a lot of people feel all more viscerally with stuff like, you know, big social medias, like hosting all your photos. You don't own any songs anymore with Spotify, and I think there's a general sense of, like, this is something that people, like, don't have that they wish they did. And in general, I think, like, one really nice thing is that with cryptographic tools, with signatures, with signed data and all sorts of different things, you get to actually, like, own your own data and have it be verifiable. But then if you want to actually maintain privacy on top of this, it works hand in hand with other tools like ZK. And really, if you own something, it is almost to some extent private to you. You should be able to keep it to yourself unless you want to share it. And a lot of cryptographic tools give you exactly that. Another is the idea of user consent. And this comes up in a really interesting way with something called multi-party computation, which is this cryptographic tool where multiple parties get to sort of do a computation on their private data. There's actually a really nice feature where if one of the parties leaves the protocol or otherwise just decides that they don't want to be a part of it, no result is reached. And I think this is actually a very nice positive feature where it's usually viewed in a lot of protocols as like a bug where user consent is almost like mathematically required. And I think this is like an offensive useful thing that people would be able to understand. Another side of portability or interoperability or verifiability, like they're all kind of the same thing. And I think a bunch of really cool use cases of this, like one is like portable social graphs. This is like an app experience that I've been building with my team where you're essentially tapping different folks and building a private social graph that also you can take with you to other apps as you wish. And I think this is something that a lot of us are feeling now when we're like locked into sort of social medias that aren't really working for us anymore. Another really good example is just all personal data. Stuff like ZK email enables you to take things in your own email and basically make proofs about them, share them with other people in a way that means they don't need to just live in one service. And finally, I think an underrated one is efficiency. There's this new idea that we've been exploring called narrowcasting, which essentially, basically, if people do have their own ownership and privacy over their own data, you can basically send messages in a way that will only be read by the people who match this criteria. And so in a sense, you can actually use cryptography to more efficiently disperse information in a way that's privacy-preserving. Really quick, where you can experience this, we have a booth downstairs, my team cursive, where we're showing an app experience that has a bunch of these different features baked in. One thing I'll call out is something called private set intersection, which lets you see what you have in common with other folks. And, yeah, there's going to be some more features added in. This is where it is in the booth. And, yeah, that's the talk.",
"eventId": "devcon-7",
- "slot_start": 1731469800000,
- "slot_end": 1731470400000,
+ "slot_start": 1731495600000,
+ "slot_end": 1731496200000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/19uBY8dZebCAmZtuh27GvgwcgDo7WY_BpHnT84sKBL6M",
+ "resources_presentation": "https://docs.google.com/presentation/d/1osFBDl_IG67iwDmsSkuzzcHEUPFlkirPaPwWwqi5bwE",
"resources_slides": null,
"speakers": [
- "leo-bautista-gomez"
+ "vivek-bhupatiraju"
]
},
"vector": [
@@ -501339,10 +500305,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -501601,6 +500565,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -501800,7 +500765,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -502106,7 +501070,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -502115,6 +501078,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -502151,7 +501115,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -502192,6 +501155,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -502210,6 +501174,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -502437,7 +501402,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -502648,9 +501612,8 @@
0,
0,
0,
- 2,
- 0,
0,
+ 2,
0,
0,
0,
@@ -502670,39 +501633,31 @@
},
{
"session": {
- "id": "lunarpunk-endgame",
- "sourceId": "EVHFWA",
- "title": "Lunarpunk Endgame",
- "description": "Global surveillance is a static world where change is surpressed and society cannot evolve. In contrast, an anonymity-enhanced world resembles a forest. New civilizational experiments blossom like flowers, radiating outward from the freedom-fighters of the future.\r\n\r\nThe lunarpunk end game is to enable a new ecology of social orders. This talk will describe the grand vision of lunarpunk: multipolar space-faring civilization, human speciation, and the reproduction life throughout the cosmos.",
- "track": "Cypherpunk & Privacy",
- "type": "Talk",
- "expertise": "Beginner",
+ "id": "manu-alzuru",
+ "sourceId": "GNMHSF",
+ "title": "Manu Alzuru",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
"audience": "Engineering",
- "featured": true,
+ "featured": false,
"doNotRecord": false,
- "keywords": [
- "Lunarpunk"
- ],
- "tags": [
- "Network State",
- "Anonymity",
- "Autonomous World",
- "lunarpunk",
- "Anonymity",
- "Autonomous World",
- "Network State"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "rachel-rose-oleary"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731488400000,
- "slot_end": 1731490200000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1pdPYWGnlJDvugH2zzLYqzKQrvDlutN5EGd8EBIpbeR4"
+ "slot_start": 1731657600000,
+ "slot_end": 1731661200000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1tmd6B8VQ5hfKNgdhvR9sH6CcRr1hFUIZc4PvRiCPHFM"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -503169,7 +502124,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -503481,7 +502435,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -503502,7 +502455,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -503565,7 +502517,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -503868,22 +502819,18 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -504020,6 +502967,7 @@
0,
2,
0,
+ 0,
2,
0,
0,
@@ -504038,63 +502986,54 @@
},
{
"session": {
- "id": "maci-why-do-we-need-private-voting-and-what-are-we-up-to",
- "sourceId": "TCJJW3",
- "title": "MACI - Why do we need private voting and what are we up to",
- "description": "MACI is a protocol that can be used to run private on chain polls. This talk will introduce the protocol, dive into some of the technical aspects. Finally we will talk about the team's plans for the future and how the community can get involved to help improve the project.",
- "track": "Applied Cryptography",
- "type": "Lightning Talk",
+ "id": "maximum-viable-security-mvs-a-new-issuance-framework",
+ "sourceId": "KWUF3N",
+ "title": "Maximum Viable Security (MVS) – a new issuance framework",
+ "description": "We derive a new framework for analyzing Ethereum Issuance, based on Ethereum's core values: security and neutrality. Upon discussing various attacks on Ethereum, we study future growth projections and the importance of diverse validator set, and conclude that Ethereum's defendability is the key factor for issuance policy evaluation. Via MVS, we show how the current issuance reduction proposal is dangerous, based on the future staked ETH concentration with CEXs & impact on solo stakers.",
+ "track": "Core Protocol",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Coordination",
- "Quadratic Voting",
- "Public good",
- "voting",
- "Coordination",
- "Public good",
- "Quadratic Voting"
- ],
"keywords": [
- "Privacy",
- "Voting"
+ "neutrality",
+ "autonomy",
+ "validator set composition"
+ ],
+ "tags": [
+ "Staking",
+ "Validator Experience",
+ "Security",
+ "composability",
+ "validator",
+ "set",
+ "Security",
+ "Staking",
+ "Validator Experience"
],
- "duration": 606,
"language": "en",
- "sources_swarmHash": "3e12944268e30652d72b931cdbdd1bf68e19741b4d3f57dd9daf2464127f2dd6",
- "sources_youtubeId": "18KFAia72Ww",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732ffcf80d989c5b7b957f9.vtt",
- "transcript_text": " yeah just works works yes I work at PC we do a lot of program of photography cool stuff comes to us we have a booth there yeah this is Macy in five minutes and my private what is important just an agenda will talk through what is Macy in five minutes and why private voting is important. Just an agenda. We'll talk through what is Macy, why do we need it, how it works, and just look into the future. So Macy stands for Minimal Anti-Collusion Infrastructure. And in a nutshell, it's a protocol that allows to run private on-chain voting. These are some of the properties that we try to push. So collusion resistance is increased because there's only one entity which can be certain of the validity of the vote. If that is trusted, then things get a little bit all the votes are encrypted. You can also, you can edit a vote by newly finding it, but whatever is set on chain must be processed. And even if we talk about this trusted entity, a coordinator, even if they are malicious, they cannot really produce any false output of the vote. So why do we need this? I mean, I think voting is a very sensible topic. Bribery and collusions happens everywhere. And I think something that a lot of people find very close to. And it's great to work on this for that reason. But yeah, like, let's take an example, like, which are the funding or voting, where more people coming together can actually make a difference. But if it's easy to collude, then the results can be gained. And also think, like, if you know how people vote, then you can also be conditioned. Like, there's some people just don't want to spend some time going through the candidates or whatever you're voting for. And you see like a famous person, oh, cool, I voted for this. Why don't I just do it? But if you don't really know, they cannot prove to you that that's actually their valid vote, then you could just maybe think for yourself. And then bribery is reduced because it's hard to prove and it's hard to collude. And our goal is to make voting more democratic and fair. So in a nutshell, the architecture, the smart contracts that work on any EVM chain, there's some circum circuits that can be used, are used to prove that all the votes sent are valid or invalid. And the tally circuit, which tallies all the votes. So this is a run by this trusted entity, the coordinator, and all the results are posted on chain for everyone to verify. Yeah, there's some SDKs and TypeScript stuff if people want to integrate it. Hopefully you do. And yeah, how does it work? As a user flow, you come and register into the platform. You register with your Macy key, which is not to be confused with your Ethereum key. You can just prove you're human, prove you own a Zupas ticket, and then you register into the system. Then you can send encrypted votes that only the coordinator is able to decrypt. And you also sign them with this Macy private key, so no one else can send votes on your behalf. And then as a user, after the coordinator processes everything, you want to verify that everything was done correctly. The votes are encrypted using a CDA, so there's a share key between you and the coordinator. It is signed, and in the vote, you specify who you're voting for, whether it's like a yes or no vote, or like you're giving some sort of weight in which you're voting. And yeah, that's encrypted, send on chain, fully encrypted, and you also send a public key that you used to generate the share key so the coordinator can just reverse the process. To finalize, the coordinator just takes all of the votes and just all the events from these smart contracts and then just generates the secret proofs using the circuits that we talked about, and they'll just post them on chain. They cannot censor any vote, they cannot prove something that is not happened, so that's some of the cool stuff about it. And yeah, looking into the future, what we try to do is to make it easier for people to use and actually get someone to use it. Some of the research topics that we have planned is to actually decentralize this coordinator figure using MPC and try and make it even more harder to collude. There might be some time to also look into new voting mechanisms, or like funding mechanisms that could be integrated. And maybe we'll also be thinking how to rethink the architecture and kind of integrate it with a lot of other PSE protocol, like Semaphore, R&R, and Exuvia. Okay, so we are running a DEF CON QV round. There's like 250K put by the impact teams at DEF CON. So you can go and vote. You can try Macy. You just need to prove you're an attendee by using Zupas. This is what it looks like. Just try it out. Just be gentle, because, yeah, just be gentle with this app. Don't break it looks like. Just try it out. Just be gentle, because yeah, just be gentle with this app. Don't break it, please. But yeah, that's just showcase how Macie work. And yeah, that's it. Five minutes. Thank you, Alessandro. Questions? Do you want to try this one for me? Thanks. Sorry, dude. You mentioned at one point that there was a proof of humanity required for the voting. How do we achieve that without relying on a centralized entity? And also, how do you protect against civil attacks in your voting chain? Yeah, that's a good question. So to prevent civil attacks, we have this concept of gatekeepers. So you need to prove that's fully customizable. So whoever runs the vote will say, hey, I'm only accepting someone that approves. It's a DEF CON, so by scanning a ticket or, like, on something like an NFT and other things. So that's how we put it against Sibyls. So Macy's is only as good as the Sibyls solution that you decide to use. And for the trusted assumption is that this coordinated figure could be removed with the NPC. So you have, like like a collaborative snark. I mean, I'm not really good into this stuff. So at a high level, just like instead of having one coordinator, you have multiple and there might be some sort of consensus, some sort of way of, how to say, to make it hard for them to also not post the results and not collude between themselves. But yeah, that's probably where we're going. And some smart people in PSC that already thought how Macy would look with MPC. So hopefully we'll be able to implement that very soon. I think we have a question at the back there. In the beginning, the receipt, receipt freeness of the vote and that it's impossible to show who you voted for. But what if the user would simply share their private keys and then reveal everything that they did, they would still be able to prove the vote in that situation. Yeah, that's a good point. So the thing is, like, when you cast a vote, you can nullify it. So I show you, hey, I voted for this, but then you couldn't trust me that I actually did, unless the coordinator colludes with this other entity. And yeah, one of the other issues is if you give out your key, then they will be able to post votes on your behalf. So it's up to the user to not sell the key. Yeah, that would kind of mess up with the system as well. And hopefully we'll be able to find some good solution for that. Yeah. I think there's a system called something with bear vote, like the animal that has a property like you need an additional salt to prove that it was actually you. And if you provide a wrong salt in the proving process, the result comes off of somebody else's vote. Okay, I'm not familiar with this, to be honest. But yeah, if you just hit me up later and just describe this, that'd be interesting to talk about. Any other questions? Yeah, I have some questions. There is any possibility you have a credential for get about your knowledge, for example, you know computer science and there is a proposal for some upgrade in the system. There is any possibility to do this? So like to automate, some sort of execution after the tile is produced? Yeah, the proposal is made, you get a vote, and the calculation of your knowledge is the quadratic voting. And then there's some sort of action that happens after? Like, that's what you mean, like, in, let's say, DAO governance or something? Yeah. Yeah, okay. That's not something we explore yet, DAO governance. Actually, I talked to a lot of people about it today. So, yeah, that's still possible. It's the tallies posted on-chain, so they can be automated as a hook. After the tally is fully approved, on-chain is the data, something can happen. That's totally doable, yeah. Yeah, thank you.",
- "eventId": "devcon-7",
- "slot_start": 1731394800000,
- "slot_end": 1731395400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1paq5inxTY__nUEseJKES2bwcdoZZSvs-h5ZpEXOfwsg",
- "resources_slides": null,
"speakers": [
- "ctrlc03"
- ]
+ "artem-kotelskiy"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731556800000,
+ "slot_end": 1731558600000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ykeBOYepaHLNtCV-zLYv6QDLjqI6Dn-EYre6XtHK8lo"
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -504833,6 +503772,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -504870,6 +503810,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -504942,9 +503883,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -504963,6 +503901,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -504988,7 +503927,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -505042,7 +503980,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -505194,7 +504131,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -505250,6 +504186,9 @@
0,
0,
0,
+ 2,
+ 2,
+ 2,
0,
0,
0,
@@ -505398,8 +504337,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -505416,48 +504355,38 @@
},
{
"session": {
- "id": "making-defensive-technology-offensive-how-to-get-cypherpunk-ideals-to-the-masses",
- "sourceId": "RGMXQ7",
- "title": "Making defensive technology offensive: How to get cypherpunk ideals to the masses",
- "description": "Cryptography is an inherently defensive tool; it hides your information from adversaries. This is crucial to prevent censorship or monitoring of your data. But it's often sold to consumers with fearmongering about all-powerful malicious actors, which is often ignored by all except the privacy-conscious. We explore real-life examples of offensive cryptographic affordances like interoperability, efficiency, and user consent as stronger motivations for the masses to migrate to cypherpunk tech.",
- "track": "Cypherpunk & Privacy",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "id": "memecraft-effectively-communicating-crypto-concepts",
+ "sourceId": "FAKRPS",
+ "title": "Memecraft: Effectively Communicating Crypto Concepts",
+ "description": "Memes have been crucial to the proliferation of various concepts and ideas within the crypto space (ultrasound money, (3,3), regen/degen, QF) which has led to real capital being allocated toward impactful outcomes. The downside to some of this memeing however has been misleading narratives and misunderstandings. How do we leverage memetic power for education and tacit understanding of complex concepts?\r\n\r\nThe workshop will include 1) Scene Setting 2) Structured Discussion and a 3) Group Activity.",
+ "track": "Coordination",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Frameworks",
- "Values",
- "Use cases of cryptography",
- "messaging",
- "Frameworks",
- "Use cases of cryptography",
- "Values"
- ],
"keywords": [
- "d/acc",
- "adoption",
- "messaging"
+ "memes"
+ ],
+ "tags": [
+ "Public good",
+ "Marketing",
+ "User Research",
+ "memes",
+ "Marketing",
+ "Public good",
+ "User Research"
],
- "duration": 352,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "W5bRYUO-Wk8",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": "6734a08f9dbb7a90e1469361",
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734a08f9dbb7a90e1469361.vtt",
- "transcript_text": " Cool. Hi, guys. So my talk is going to be about basically, like, focused on cryptography as defensive technology, because that's my area of expertise, how we can take various cryptographic tools that are super powerful and try to find ways to be clear this is more like encryption signatures EAPs this sort of thing obviously under the umbrella of like DIAQ and defensive technologies there's lots of other stuff going on and I think how I would personally define cryptography is that it's the art of making things hard to break in this definition it is like very inherently a defensive technology you're literally trying to make tools that is very difficult for adversaries to forge or break into or otherwise sort of damage the integrity of. And I want to look at just a very small set of examples here. This is not comprehensive at all, but at one really prominent use case of privacy-preserving technologies in the wild, which is VPNs. And VPNs, I think if any of you guys have been to, like, New York or Chicago or a couple other major American cities, you might have seen these, like, Mulvad VPN ads everywhere. For context, I personally use Mulvad, so this is not really a dig at them, but a lot of their ads are very sort of, like, a bit of both, like, hopeful, but also kind of, like, fear-mongery, and I honestly am not sure how successful this has been for them. I definitely know for myself, like, I got Mulvad before these ads came on, and, like, when I do see them in, like, the subway, in the train, I'm, like, I always think, like, is this, like, do people want to see this sort of thing? And, like, one reference point in my mind that I have is NordVPN, a lot of these other VPNs, this is not actually an ad from them, to be very clear, but if you're a big YouTube user, you know that Nord and Express, these sort of VPN companies, are major funders of every YouTuber. And it's really interesting to see how that marketing has changed over the past few years. I feel like initially it was very much focused on, oh, this will protect you from your internet provider seeing your history. And often that's still mentioned, but actually most of the time now, the emphasis of the ad reel is always on you can watch Netflix in other countries. You can do this new, you have this new affordance from using this VPN. And it's always kind of what they talk about for a little bit longer. And I feel like it is a very good representation of the fact that I think users will generally respond to things that are value adds and not purely sort of defensive measures against some sort of threat. And to be clear, I'm very much a cypherpunk, and I deeply believe in this technology. But at the same time, I also believe that if we're not able to do this sort of communication work, we're not going to be able to get users the defense and safety that they deserve. And so I want to talk through just a few different kind of like high level affordances that I think are worth leaning into and talking about more. The first is the idea that privacy is really ownership. And I think ownership is something that a lot of people feel all more viscerally with stuff like, you know, big social medias, like hosting all your photos. You don't own any songs anymore with Spotify, and I think there's a general sense of, like, this is something that people, like, don't have that they wish they did. And in general, I think, like, one really nice thing is that with cryptographic tools, with signatures, with signed data and all sorts of different things, you get to actually, like, own your own data and have it be verifiable. But then if you want to actually maintain privacy on top of this, it works hand in hand with other tools like ZK. And really, if you own something, it is almost to some extent private to you. You should be able to keep it to yourself unless you want to share it. And a lot of cryptographic tools give you exactly that. Another is the idea of user consent. And this comes up in a really interesting way with something called multi-party computation, which is this cryptographic tool where multiple parties get to sort of do a computation on their private data. There's actually a really nice feature where if one of the parties leaves the protocol or otherwise just decides that they don't want to be a part of it, no result is reached. And I think this is actually a very nice positive feature where it's usually viewed in a lot of protocols as like a bug where user consent is almost like mathematically required. And I think this is like an offensive useful thing that people would be able to understand. Another side of portability or interoperability or verifiability, like they're all kind of the same thing. And I think a bunch of really cool use cases of this, like one is like portable social graphs. This is like an app experience that I've been building with my team where you're essentially tapping different folks and building a private social graph that also you can take with you to other apps as you wish. And I think this is something that a lot of us are feeling now when we're like locked into sort of social medias that aren't really working for us anymore. Another really good example is just all personal data. Stuff like ZK email enables you to take things in your own email and basically make proofs about them, share them with other people in a way that means they don't need to just live in one service. And finally, I think an underrated one is efficiency. There's this new idea that we've been exploring called narrowcasting, which essentially, basically, if people do have their own ownership and privacy over their own data, you can basically send messages in a way that will only be read by the people who match this criteria. And so in a sense, you can actually use cryptography to more efficiently disperse information in a way that's privacy-preserving. Really quick, where you can experience this, we have a booth downstairs, my team cursive, where we're showing an app experience that has a bunch of these different features baked in. One thing I'll call out is something called private set intersection, which lets you see what you have in common with other folks. And, yeah, there's going to be some more features added in. This is where it is in the booth. And, yeah, that's the talk.",
- "eventId": "devcon-7",
- "slot_start": 1731495600000,
- "slot_end": 1731496200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1osFBDl_IG67iwDmsSkuzzcHEUPFlkirPaPwWwqi5bwE",
- "resources_slides": null,
"speakers": [
- "vivek-bhupatiraju"
- ]
+ "joshua-davila",
+ "beth-mccarthy"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731642000000,
+ "slot_end": 1731643800000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1WKMS7RU7L0T4jR34wKgLFODsY4ligbUzbHahkZWhf6I"
},
"vector": [
0,
@@ -505465,13 +504394,13 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -505725,7 +504654,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -505926,6 +504854,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -506240,7 +505170,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -506296,6 +505225,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -506336,8 +505266,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -506499,6 +505427,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -506770,14 +505699,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -506789,42 +505716,42 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "manu-alzuru",
- "sourceId": "GNMHSF",
- "title": "Manu Alzuru",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
+ "id": "merkle-proofs-when-leaves-leave-you-vulnerable",
+ "sourceId": "LAKCG3",
+ "title": "Merkle Proofs: When Leaves Leave You Vulnerable",
+ "description": "A Merkle proof is a cryptographically authenticated data structure widely used to minimize on-chain data storage. The Merkle algorithm is neat yet non-trivial to implement correctly and securely; its leaves may leave you vulnerable if not handled properly.",
+ "track": "Security",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Merkle"
+ ],
+ "tags": [
+ "Auditing",
+ "Bug",
+ "merkle",
+ "Auditing",
+ "Bug"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "shufan-wang"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731657600000,
- "slot_end": 1731661200000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1tmd6B8VQ5hfKNgdhvR9sH6CcRr1hFUIZc4PvRiCPHFM"
+ "slot_start": 1731390000000,
+ "slot_end": 1731390600000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1_G-GfGgNMUn5tiiaH-Srat0PLHtYYRNtiVjZwWlxU_c"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -507292,6 +506219,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -507725,6 +506653,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -507846,6 +506775,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -507989,6 +506919,40 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -508098,41 +507062,10 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
2,
0,
0,
+ 0,
2,
0,
0,
@@ -508151,54 +507084,59 @@
},
{
"session": {
- "id": "maximum-viable-security-mvs-a-new-issuance-framework",
- "sourceId": "KWUF3N",
- "title": "Maximum Viable Security (MVS) – a new issuance framework",
- "description": "We derive a new framework for analyzing Ethereum Issuance, based on Ethereum's core values: security and neutrality. Upon discussing various attacks on Ethereum, we study future growth projections and the importance of diverse validator set, and conclude that Ethereum's defendability is the key factor for issuance policy evaluation. Via MVS, we show how the current issuance reduction proposal is dangerous, based on the future staked ETH concentration with CEXs & impact on solo stakers.",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "modern-zkp-compilers",
+ "sourceId": "CV7QXP",
+ "title": "Modern ZKP compilers",
+ "description": "At PSE we have done much ZKP advanced development. From that learning we are building a language and compiler, that is summarizing much of this learning.\r\nWe answer questions like: Are compilers necessary in a zkVM world? What is the role of a compiler in ZKP development? What are its most common components? How different ways can this problem be approached?\r\nIn this advanced talk, we will learn how we compile arbitrary boolean expressions, or how the Schwartz–Zippel lemma can be used to optimize",
+ "track": "Applied Cryptography",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "neutrality",
- "autonomy",
- "validator set composition"
- ],
"tags": [
- "Staking",
- "Validator Experience",
- "Security",
- "composability",
- "validator",
- "set",
- "Security",
- "Staking",
- "Validator Experience"
+ "Developer Infrastructure",
+ "Languages",
+ "ZKP",
+ "education",
+ "Developer Infrastructure",
+ "Languages",
+ "ZKP"
],
- "language": "en",
- "speakers": [
- "artem-kotelskiy"
+ "keywords": [
+ "education"
],
+ "duration": 645,
+ "language": "en",
+ "sources_swarmHash": "ff06f4ba851b1ea9b39cae607b1ef0d62e19962feb32f62ee1611e236c5b5a1c",
+ "sources_youtubeId": "JX9YtcG_EHk",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fcf780d989c5b7b0bffb.vtt",
+ "transcript_text": " Hi everyone. So we are going to talk about the project that we were working on at PSC. That, I mean, when we apply for this speaking about this, we were working on this but now we have stopped working on this. So we are going to go through what we were doing and the reasons why we stopped working on this. So, a little bit of the retrospective of a project, let's say. I started working in 2022 on the CKVM that at that moment PSC was working on, that was based on Halo 2 kind of a plonkish arithmetization. And because it was very complicated to build something like that on top of Halo 2, it's inevitable that you need to abstract things. So as an engineer, I found there like a treasure trove of really interesting abstractions to be able to build the CKEDM on top of Halo 2. A lot of layers on top of the Halo 2 to be able to reason about it and to kind of like, yeah, abstract on it and build what we required. And there's things like the state machines, it seems like it was the right level of abstraction to think about proving computation on top of Planck's arithmetization and the cell manager that was used to kind of place things in a more efficient way on the Blanquist table and also how to combine like composability with something that was called the super circuit answer so again this all this was built when I started working here but I start kind of learning learning about it and I found like this idea that these abstractions actually, if they are made in an accessible way, could make much more easy for the average developer to develop CK apps. And that something like this could help multiply CK apps development. And with that, we started Chiquito. First, as a DSL in Rust, then we added a Python frontend to make it even simpler with the idea that developers didn't need to learn Rust. They could do it on Python. And then after bringing it to several hacker houses and working with builders at the experimental level, with more information about how it should be built, we started creating our own parser for a language that has a similar syntax to Zircon but has state machines and more things. So in the end, what we implemented the state machines that as the definition like the constraints of the transitions of state definition like the constraints of the transitions of state machines are kind of the circuit and the witness is the trace of instance of execution of these state machines and that's kind of like the main abstraction at Chiquito and then with the cell managers we abstract how that is converted to the Planck table and how the witness is arranged in an efficient way and can be, is independent so can be configured in different ways to try different things. Then another thing that we built is like arbitrary Boolean expressions compilation to polynomial identities, no? So the constraints are expressed as polynomial identities. And we build a system that any Boolean expression, as complicated as necessary, it will be automatically compiled to this. And we kind of develop a mini theory about how to build this, that can be used in other languages, like how to compile any Boolean expression into polynomial identities. Then we also, like, compilers has to optimize, and through optimization can get to better performance. Wow, I'm going super slow. So, yes, we did more things, and this is how it looks, the code. And, yeah, you can, can, for example, here, you can see arbitrary Boolean expressions that are compiled automatically to constraints. And we saw it was super easy. And users really quickly could develop complicated things, like Blake2 hash that in the CKVM we couldn't implement on top of Halo 2 normally with it. And we checked that it has the same performance as manually doing with Hello2. And we found some things that can be better. And then the reasons to sunset it is basically CKVMs, the race of CKVMs make us reason that now we are in a kind of CKVM era that the applications we want to build now are probably better built on CKVMs. Thank you for all the people participating in different stages on Chiquito, PSC engineers, researchers, and grantees. Thank you very much. Thanks, Leo. Question time. I had to accelerate a lot. Any questions? Oh, there. Go closer. I wanted to throw it. You can do the next. It's okay. Hey, Lance. Yo, what's up, Leo? So question on custom constraint systems. I saw that there was one of the libraries that you all used. When it comes to CCS and ZKVMs, are there any ZKVMs that are implementing for that to go from like Plonk to Air? But that wouldn't be like to go from Plonk to Air? That would be kind of an easy translation, I think. Not a VM, but from Plonk to Air would be kind of an easy translation, because the difference is kind of how the rotations work in the arithmetization. We actually implemented the backend as Powder, that is kind of Air. Powder? Powder, yeah. I cannot show this. Yeah, I'm familiar. Yeah, so we implemented a backend for Powder that is kind of air, yeah, so, yeah, that's, it's easy, Plonkish and even CCS, we implemented the backend in CCS, Sonove, so, yeah, it compiled to, we didn't have time to check the performance on Sonove, but it was something that was compilable to many different brewing systems. Really cool. I think there's a question here. You want to throw it? This one. Oh. Hi, thank you. Nikolai from terminal 3. A few questions actually. First, can I verify your proof on chain, like in BN254? That's basically the only one chain verifier now. And then you said you'd made Python, but can I do a Rust code and compile it? Because most of cryptography is in Rust, so Rust is very useful here. Let's do these two and then if you want... Okay, okay. Sorry, don't forget. So the first question on chain, yes, so we, for the CKVM, we implemented a verifier in Solidity for the Hello2 proof. So as long like, it depends on the proving system that's used in the backend. If it can be verified on, because it's kind of independent on the proving system, can compile to different proving systems, and they generate different proofs. So it depends on that. And the second question, Rust, it's built on Rust. Chiquito was built on Rust, and then we put like a parcel of frontend. But yes, you could interact and connect it with other Halo 2 circuits built on Rust and kind of actually integrate it together. And another question? One more. OK, we have one more question. OK, there. Yeah, better you throw it. You want to throw it again? OK, there. Yeah, better you throw it. You want to throw it again? Okay, okay. Last opportunity. Too short. Go back. So I'm actually not sure I understand the difference between a ZKVM and a ZK compiler. Like a ZKVM takes your Rust code, translates it into, let's say, RISC-V instructions, and proves that. Okay. So a ZKVM is one circuit that it witnesses the trace of the execution of an instruction set. So the ZKVM is not a compiler. It's a circuit that takes as witness the trace of the execution and proves that you have executed correctly the program. So in that case you compile RAS to this instruction architecture and then you execute it and you get the trace and that's verified. A compiler takes some kind of description of what you see to that and actually kind of outputs a circuit itself. So you could build a CKVM on a DSL in a language. I don't hear you. Yeah. So what actually executes the code? Like, what does the proof prove if it doesn't prove correct execution, right, with the compiler? Yeah, with the compiler, you generate a circuit that proves something about the witness. So a CKVM is a type of circuit, no? It's a type of circuit that proves the execution of the trace of a specific instruction set. But a circuit can prove any witness like they follow certain properties, certain constraints. In the case of the CKVM, the constraints are the correct execution of the instruction set. Happy I knew that question. I knew the answer. If they ask something different. I don't think we have time for one more question, but please feel free to talk to Leo after his talk.",
"eventId": "devcon-7",
- "slot_start": 1731556800000,
- "slot_end": 1731558600000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1ykeBOYepaHLNtCV-zLYv6QDLjqI6Dn-EYre6XtHK8lo"
+ "slot_start": 1731393000000,
+ "slot_end": 1731393600000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1XmimA6xYE2Wr9c4tzpc9e9P7XDxysFx2QT8rBsA-piQ",
+ "resources_slides": null,
+ "speakers": [
+ "leo-lara"
+ ]
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -508940,8 +507878,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -508978,7 +507914,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -508994,6 +507929,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -509014,6 +507950,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -509029,11 +507966,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -509069,7 +508008,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -509355,9 +508293,6 @@
0,
0,
0,
- 2,
- 2,
- 2,
0,
0,
0,
@@ -509505,7 +508440,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -509518,43 +508452,31 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "memecraft-effectively-communicating-crypto-concepts",
- "sourceId": "FAKRPS",
- "title": "Memecraft: Effectively Communicating Crypto Concepts",
- "description": "Memes have been crucial to the proliferation of various concepts and ideas within the crypto space (ultrasound money, (3,3), regen/degen, QF) which has led to real capital being allocated toward impactful outcomes. The downside to some of this memeing however has been misleading narratives and misunderstandings. How do we leverage memetic power for education and tacit understanding of complex concepts?\r\n\r\nThe workshop will include 1) Scene Setting 2) Structured Discussion and a 3) Group Activity.",
- "track": "Coordination",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Community",
+ "id": "mood-rebalancing-singing-bowls-handpan",
+ "sourceId": "SVAHJU",
+ "title": "Mood Rebalancing (Singing Bowls + Handpan)",
+ "description": "By Most Handpan X Ice\r\nThis session helps you feel emotionally centered and peaceful.\r\n- Bring balance to your emotions with singing bowls and handpan. \r\n- Using an emotion wheel, you’ll explore and understand your feelings, a key step to managing them. \r\n\r\nNov 15 10:30 - 11:15",
+ "track": "Entertainment",
+ "type": "Mixed Formats",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "memes"
- ],
- "tags": [
- "Public good",
- "Marketing",
- "User Research",
- "memes",
- "Marketing",
- "Public good",
- "User Research"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "joshua-davila",
- "beth-mccarthy"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731642000000,
- "slot_end": 1731643800000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1WKMS7RU7L0T4jR34wKgLFODsY4ligbUzbHahkZWhf6I"
+ "slot_start": 1731641400000,
+ "slot_end": 1731644100000,
+ "slot_roomId": "decompression-room",
+ "resources_presentation": "https://docs.google.com/presentation/d/1STERW4iF8WxYtoPJQKN2mZr5qwM1yuH_XYRcXEVM1pw"
},
"vector": [
0,
@@ -509566,8 +508488,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -510026,8 +508946,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -510396,7 +509314,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -510418,7 +509335,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -510599,7 +509515,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -510727,7 +509642,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -510870,13 +509784,13 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
2,
@@ -510887,42 +509801,46 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0
]
},
{
"session": {
- "id": "merkle-proofs-when-leaves-leave-you-vulnerable",
- "sourceId": "LAKCG3",
- "title": "Merkle Proofs: When Leaves Leave You Vulnerable",
- "description": "A Merkle proof is a cryptographically authenticated data structure widely used to minimize on-chain data storage. The Merkle algorithm is neat yet non-trivial to implement correctly and securely; its leaves may leave you vulnerable if not handled properly.",
- "track": "Security",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
+ "id": "mood-uplifting-singing-bowls-handpan",
+ "sourceId": "H7Y7L8",
+ "title": "Mood Uplifting (Singing Bowls + Handpan)",
+ "description": "By Most Handpan X Ice\r\nThis session fills you with positive energy, boosting your mood and clearing your mind.\r\n- Lift your spirits with the bright sounds of singing bowls, handpan, and soft percussion. \r\n\r\nNov 14 15:00 - 15:45",
+ "track": "Entertainment",
+ "type": "Mixed Formats",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Merkle"
- ],
- "tags": [
- "Auditing",
- "Bug",
- "merkle",
- "Auditing",
- "Bug"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "shufan-wang"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731390000000,
- "slot_end": 1731390600000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1_G-GfGgNMUn5tiiaH-Srat0PLHtYYRNtiVjZwWlxU_c"
+ "slot_start": 1731571200000,
+ "slot_end": 1731573900000,
+ "slot_roomId": "decompression-room",
+ "resources_presentation": "https://docs.google.com/presentation/d/1vnIacRdbAcvTa2ioFdaqS_vlSqjDw2GnNcAukvszKyw"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
6,
0,
0,
@@ -511394,7 +510312,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -511827,7 +510744,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -511950,7 +510866,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -512094,52 +511009,44 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -512239,7 +511146,6 @@
2,
0,
0,
- 0,
2,
0,
0,
@@ -512258,45 +511164,47 @@
},
{
"session": {
- "id": "modern-zkp-compilers",
- "sourceId": "CV7QXP",
- "title": "Modern ZKP compilers",
- "description": "At PSE we have done much ZKP advanced development. From that learning we are building a language and compiler, that is summarizing much of this learning.\r\nWe answer questions like: Are compilers necessary in a zkVM world? What is the role of a compiler in ZKP development? What are its most common components? How different ways can this problem be approached?\r\nIn this advanced talk, we will learn how we compile arbitrary boolean expressions, or how the Schwartz–Zippel lemma can be used to optimize",
+ "id": "mopro-make-client-side-proving-on-mobile-easy",
+ "sourceId": "BZWFEM",
+ "title": "Mopro: Make Client-side Proving on Mobile Easy",
+ "description": "Mopro is a toolkit for ZK app development on mobile. Mopro makes client-side proving on mobile simple. Mopro aims to connect different adapters with different platforms. In this talk, we will share:\r\n- How to use Mopro to develop your own ZK mobile app.\r\n- What is the current development progress, including the current supported proving systems, supported platforms, and mobile GPU exploration results. \r\n- Moreover, we will share the challenges that Mopro faces and our future roadmap.",
"track": "Applied Cryptography",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"tags": [
- "Developer Infrastructure",
- "Languages",
"ZKP",
- "education",
- "Developer Infrastructure",
- "Languages",
+ "Cryptography",
+ "Mobile",
+ "android",
+ "Cryptography",
+ "Mobile",
"ZKP"
],
"keywords": [
- "education"
+ "iOS",
+ "Android"
],
- "duration": 645,
+ "duration": 958,
"language": "en",
- "sources_swarmHash": "ff06f4ba851b1ea9b39cae607b1ef0d62e19962feb32f62ee1611e236c5b5a1c",
- "sources_youtubeId": "JX9YtcG_EHk",
+ "sources_swarmHash": "83f2fcfab64a4052bdaa28b2c9f33ae4f5a4bccdd8fdc70865019c8ab568a649",
+ "sources_youtubeId": "0ziKiYwhJHk",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fcf780d989c5b7b0bffb.vtt",
- "transcript_text": " Hi everyone. So we are going to talk about the project that we were working on at PSC. That, I mean, when we apply for this speaking about this, we were working on this but now we have stopped working on this. So we are going to go through what we were doing and the reasons why we stopped working on this. So, a little bit of the retrospective of a project, let's say. I started working in 2022 on the CKVM that at that moment PSC was working on, that was based on Halo 2 kind of a plonkish arithmetization. And because it was very complicated to build something like that on top of Halo 2, it's inevitable that you need to abstract things. So as an engineer, I found there like a treasure trove of really interesting abstractions to be able to build the CKEDM on top of Halo 2. A lot of layers on top of the Halo 2 to be able to reason about it and to kind of like, yeah, abstract on it and build what we required. And there's things like the state machines, it seems like it was the right level of abstraction to think about proving computation on top of Planck's arithmetization and the cell manager that was used to kind of place things in a more efficient way on the Blanquist table and also how to combine like composability with something that was called the super circuit answer so again this all this was built when I started working here but I start kind of learning learning about it and I found like this idea that these abstractions actually, if they are made in an accessible way, could make much more easy for the average developer to develop CK apps. And that something like this could help multiply CK apps development. And with that, we started Chiquito. First, as a DSL in Rust, then we added a Python frontend to make it even simpler with the idea that developers didn't need to learn Rust. They could do it on Python. And then after bringing it to several hacker houses and working with builders at the experimental level, with more information about how it should be built, we started creating our own parser for a language that has a similar syntax to Zircon but has state machines and more things. So in the end, what we implemented the state machines that as the definition like the constraints of the transitions of state definition like the constraints of the transitions of state machines are kind of the circuit and the witness is the trace of instance of execution of these state machines and that's kind of like the main abstraction at Chiquito and then with the cell managers we abstract how that is converted to the Planck table and how the witness is arranged in an efficient way and can be, is independent so can be configured in different ways to try different things. Then another thing that we built is like arbitrary Boolean expressions compilation to polynomial identities, no? So the constraints are expressed as polynomial identities. And we build a system that any Boolean expression, as complicated as necessary, it will be automatically compiled to this. And we kind of develop a mini theory about how to build this, that can be used in other languages, like how to compile any Boolean expression into polynomial identities. Then we also, like, compilers has to optimize, and through optimization can get to better performance. Wow, I'm going super slow. So, yes, we did more things, and this is how it looks, the code. And, yeah, you can, can, for example, here, you can see arbitrary Boolean expressions that are compiled automatically to constraints. And we saw it was super easy. And users really quickly could develop complicated things, like Blake2 hash that in the CKVM we couldn't implement on top of Halo 2 normally with it. And we checked that it has the same performance as manually doing with Hello2. And we found some things that can be better. And then the reasons to sunset it is basically CKVMs, the race of CKVMs make us reason that now we are in a kind of CKVM era that the applications we want to build now are probably better built on CKVMs. Thank you for all the people participating in different stages on Chiquito, PSC engineers, researchers, and grantees. Thank you very much. Thanks, Leo. Question time. I had to accelerate a lot. Any questions? Oh, there. Go closer. I wanted to throw it. You can do the next. It's okay. Hey, Lance. Yo, what's up, Leo? So question on custom constraint systems. I saw that there was one of the libraries that you all used. When it comes to CCS and ZKVMs, are there any ZKVMs that are implementing for that to go from like Plonk to Air? But that wouldn't be like to go from Plonk to Air? That would be kind of an easy translation, I think. Not a VM, but from Plonk to Air would be kind of an easy translation, because the difference is kind of how the rotations work in the arithmetization. We actually implemented the backend as Powder, that is kind of Air. Powder? Powder, yeah. I cannot show this. Yeah, I'm familiar. Yeah, so we implemented a backend for Powder that is kind of air, yeah, so, yeah, that's, it's easy, Plonkish and even CCS, we implemented the backend in CCS, Sonove, so, yeah, it compiled to, we didn't have time to check the performance on Sonove, but it was something that was compilable to many different brewing systems. Really cool. I think there's a question here. You want to throw it? This one. Oh. Hi, thank you. Nikolai from terminal 3. A few questions actually. First, can I verify your proof on chain, like in BN254? That's basically the only one chain verifier now. And then you said you'd made Python, but can I do a Rust code and compile it? Because most of cryptography is in Rust, so Rust is very useful here. Let's do these two and then if you want... Okay, okay. Sorry, don't forget. So the first question on chain, yes, so we, for the CKVM, we implemented a verifier in Solidity for the Hello2 proof. So as long like, it depends on the proving system that's used in the backend. If it can be verified on, because it's kind of independent on the proving system, can compile to different proving systems, and they generate different proofs. So it depends on that. And the second question, Rust, it's built on Rust. Chiquito was built on Rust, and then we put like a parcel of frontend. But yes, you could interact and connect it with other Halo 2 circuits built on Rust and kind of actually integrate it together. And another question? One more. OK, we have one more question. OK, there. Yeah, better you throw it. You want to throw it again? OK, there. Yeah, better you throw it. You want to throw it again? Okay, okay. Last opportunity. Too short. Go back. So I'm actually not sure I understand the difference between a ZKVM and a ZK compiler. Like a ZKVM takes your Rust code, translates it into, let's say, RISC-V instructions, and proves that. Okay. So a ZKVM is one circuit that it witnesses the trace of the execution of an instruction set. So the ZKVM is not a compiler. It's a circuit that takes as witness the trace of the execution and proves that you have executed correctly the program. So in that case you compile RAS to this instruction architecture and then you execute it and you get the trace and that's verified. A compiler takes some kind of description of what you see to that and actually kind of outputs a circuit itself. So you could build a CKVM on a DSL in a language. I don't hear you. Yeah. So what actually executes the code? Like, what does the proof prove if it doesn't prove correct execution, right, with the compiler? Yeah, with the compiler, you generate a circuit that proves something about the witness. So a CKVM is a type of circuit, no? It's a type of circuit that proves the execution of the trace of a specific instruction set. But a circuit can prove any witness like they follow certain properties, certain constraints. In the case of the CKVM, the constraints are the correct execution of the instruction set. Happy I knew that question. I knew the answer. If they ask something different. I don't think we have time for one more question, but please feel free to talk to Leo after his talk.",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673309f83a168eb535ebd6e0.vtt",
+ "transcript_text": " A scaling research perspective. Yeah, so we had raised, well, first we were supposed to write the book on Plasma. And every single time, remember I was a Bitcoiner transitioning into the Ethereum world. And every single time I finished writing a chapter, the research space had progressed enough that I would have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got paid to do. Five rewrites later, we were like, wait, this is definitely an implementable design. So we implemented it, we published it, we launched a test net, we got all these likes on Twitter. I remember we had 1,000 likes. I remember screenshotting it to my parents and sending it to them. And it wasn't the same as product market fit. And so, you know, after like three months of our Plasma network, I was like, we've done it. We've scaled Ethereum. Why isn't everyone cheering? Why isn't mass adoption coming? And there had been a total of, I think, four transactions on the test network. And all four of them were our transactions. So after that, we went back to the drawing board, and we hit up some people at a firm called IDEO. And they introduced us to the concept of talking to your users. And it explains a lot about crypto. This is like a year into the development of Plasma. So for the very first time, we spoke to some users, and we said, we've got theoretically infinite transactions per second. You just have to adopt this completely new Plasma predicate system, and you have to learn a new programming language, which we've just invented. And people were like, you know, I actually don't want to do that. I'm a product manager at Coinbase and I've got a lot of shit to do and I'm not going to rewrite all my contracts. We're like, okay, Uniswap. Uniswap should be simple enough. And Hayden was like, bro, my shit is 100 lines of code. I'm not about to rewrite that shit in a brand new language. I'm doing just fine. My users are just fine paying the fees. And so we realized that what we had built was not actually what people wanted. There wasn't enough usage in crypto at the time to warrant having theoretically infinite TPS. What people wanted was cheap transactions and fast transactions. A single transaction averaged anywhere between $5 and $25 depending on what was happening. So we went back to the drawing board. But the only problem was I had raised a total of $300,000 in grant funding. And it was enough to pay each of us like $40,000. Our office was my studio apartment in New York City. I lofted my bed. Everything under my bed was like my room, and we shared one Ikea table. And it turns out if you have kids, so like if you have any experience doing any kind of work, you didn't want to work for us. And I remember offering a very senior staff engineer $120,000 a year because I thought that that was a lot of money. And he was like, no, I'm thinking like $250,000, and that was crazy to me. So tried to raise another round of grant funding. Didn't work, which was surprising to us because Omise Go, this company that had raised $30 million in ICO funding, didn't want to give us more money. The other projects that had forked our code base, including Matic, which is today Polygon, also didn't want to give us grant funding. So how could it be? Did nobody want what we were building? So we went back to the drawing board and built out a demo of the first optimistic rollup with Uniswap. The idea was we needed one-click deploy. TPS was not the optimization target. We were optimizing for fast transactions, cheap transactions. And we demoed that, and we went and raised a round of VC funding. VCs were like, how are you planning to monetize? No idea, but all I knew was we needed to start hiring more than just four half-brained kids who didn't even have their frontal cortex fully developed and have never heard of a product manager before. And that's where we are now today, four years later. Yeah, I mean, I think the way that I saw the research side of this, right, is basically that in the beginning, there were state channels. Actually, Bitcoin came up with state channels first. It was just called payment channels, and then it was called the Lightning Network. And it turns out that the Lightning Network has a lot of problems. But then state channels in Ethereum, thanks to Ethereum smart contract properties, were more powerful. But even still, there is this problem that they only supported a very narrow class of applications. And then in 2017, Plasma came along, and Plasma actually supported arbitrary scale, scalability for payments. And so at first, there was Joseph Poon's paper back in the summer. Then there was Minimal Viable Plasma, which is a post on ETH Research. And then Carl and I, I think on a train in France, came up with Plasma Cash, which is like Plasma but more scalable, right? Because like Bitcoin Cash is like Bitcoin but more scalable. And so, but then even that still, like it only supported payments, right? And then we went into this rabbit hole of like using RSA and like cryptography. And then we did plasma prime but then eventually we got like to this point where we realized that like with the technology at the time actually plasma just could not be made to be general-purpose and that just became more and more obvious and then at some point like basically the idea of roll-ups so started to come out and like people just realized that doing a roll-up that actually supports a full EVM was actually the obvious choice and what I think is interesting right is like I think short term like that was completely true right because there was also this other project from 2020 called Loopring that did a ZK rollup using, that was like fully functional, like even got to stage two very quickly, very cheap, but then nobody cared because people did not want payments, people wanted the EVM. And so then stuff switched to the rollup direction. And then more recently we realized like, wait, ZK-SNARKs exist, they're amazing. And like actually there's, with ZK-SNARKsnarks there's a lot of plasma stuff that you can do that was not actually possible before. So like I actually think there's a good possibility that in a couple of years things are gonna go like fully full circle. Oh and one foot as you could tell V was like kind of behind the scenes like doing all these things and one thing one thing I remember, I was in a car, and I was like, wait, so if you post the data in the call data, it saves X amount of money. And then Vitalik was like, oh, that sounds like Shadowchains, this thing that I wrote about in 2014. Anyway, it was a whole weird melting pot of ideas and things that all, you know, now we're here. Personally, I feel like the entire industry is doomed to talk about the same like six ideas on like an eight month loop to infinity. Maybe I'll be convinced that I'm wrong in a few years, but this is my current thesis. So just trolling a little bit. Yeah. Well, so I think switching gear a little bit, since Hayden cannot make it here, Uniswap also has a really interesting story like Carl mentioned. But it may be one of the earliest and most usable applications. And there's a lot of MEV in there. There's a lot of how to build an application on Ethereum. Like I would say lessons learned. So yeah, maybe I'll give it to V first because he's, yeah, I guess. Sorry, what's the question? Okay. Okay, I'll grab it. Basically, I mean, there is a untold Uniswap side of the story, which I told Hayden that I would also do, so I feel obligated to answer your question. I hope you don't mind. Which is that Hayden also was behind the scenes talking about this. And I talked about this in a presentation, DevCon 4 or whatever. But basically, I remember many times we were in Brooklyn with Hayden, with the Uniswap team, going to their office saying, hey, check out our new design. It's so scalable and it's so great. And as Jing said, it was a predicate design or whatever. And then Hayden was like, okay, but can it support Uniswap? And the answer was, no, it cannot. And we went through design after design after design after design. And eventually we finally, finally came to this you know to the optimistic role of design which actually could support Uniswap and so Hayden and really the Uniswap team has been like you know very much you know kind of a guy a guiding light for what it means to build a successful application because Uniswap is a successful application that has users. Surprise, surprise. Not like our plasma design. Anyway. Yeah. I mean, one other fun thing about Uniswap is I think there's this, like, other even deeper rabbit hole where the ideas came from, right? Which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right, which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right? So basically what happened was that people were thinking about prediction markets all the way since, like, the 1980s and 90s. And then one problem that they faced is, like, situations where they wanted the market to stay liquid even in the face of, like, relatively few users. And they wanted a way for people who are publicly interested in learning the outcome and willing to pay for it, a way to subsidize the market. And so out of that, there were these ideas that were called market scoring rules that were basically like the equivalent of making an infinite number of infinitesimal bids and asks at every price level, right? And if you actually do the math on this, this just converts into very basic functions. There's one that's called the logarithmic market scoring rule. There's one called the quadratic scoring rule. And I knew about these because I was a prediction market fan. And then at some point, this idea clicked and I wrote this Reddit post that basically said, let's run on-chain decentralized exchanges the way that we run prediction markets. And the idea there was, well, there were on-chain DEXs before. They used order books. They had horrible spreads. They were ugly to use. And so let's, like, use this idea of, like, just having an on-chain curve that you can, like, buy and sell along and let's figure out the curve. And then I wrote this post and then about six months later I wrote another post basically defending why you can't like drain the thing of money and then about a year later like basically Haydn came along and like that actually yeah became implemented right and then of course since then like those this and then prediction markets themselves turn into designs where like you just issue tokens and you just have an AMM between tokens so like everything went full circle multiple times I'm sorry I got too markets themselves turn into designs where you just issue tokens and you just have an AMM between tokens. So everything went full circle multiple times. I'm sorry, I got too excited. But just as all good ideas are recycled, the good idea of building an X times Y equals K market maker was really Vitalik being like, Carl, this is very obviously something that needs to be built, and no one is building this idea that I have. And I'm like, oh, well, I happen to have someone, as you said, who's right there for it. So anyway, good old me. I was actually very offended by the early Uniswap designs, because I was like, oh, my God, these people, they want their kind of libertarian like info prediction market so bad that they're not thinking about the consensus consequences of exposing all this MEV and what it's going to do to validators, stake centralization over time, kind of concentration to places like Wall Street. And I sent Vitalik like a super angry rant. It might have even been all caps. I don't have it anymore because I used to run my own email server and that got nuked by a third tier VPS provider. But that's its own rant. But I was like, wow, this is horrible for a consensus. How can we advocate this design? This is literally unlimited MEV per block. The entire liquidity, the entire order flow, it's like, it could not be worse. Can't we do something more like the EtherDelta design with a little limit kind of system, maybe an off-chain component? It's not great. It's a little more centralized, but it's at least how we know how to solve the problem right now. And it doesn't expose infinite MEV the way this design was. And I think Vitalik sent back one line. He was like, well, we can maybe just consider this fees for users to have their transactions executed. And I was super offended. I was like, what do you mean fees? Like, how do you extract this? How do you, like, blah, blah, blah, blah, blah. And I think now what we have in production is Uniex, which in some ways was, like, my original suggestion to them to what to do instead. When they launched it, I was like, what are you doing? Like, you finally fixed all the problems with, like, the old design. It's finally convinced, like, me that it's the right thing. And now you're going back. Like, so, yes, TLDR, I do feel like we're just circling, like, the same four things. We're probably going to see permissionless AMMs come back at some point. This is kind of like a call to the room in various settings, this is my opinion, that are kind of even decoupled from L2s completely. So sorry, optimism, but it's going to be both. So that's my trolling today. Yeah, so, well, speaking of things going back in circles, that Robin Henson today just, or these past 48 hours just launched a prediction market on aetherium right it's kind of crazy and to think about how the real world is you know impacted well I guess we are in the real world. So speaking of that, I know Vy needs to bounce at some point. Skedaddle. I have no idea what that is. OK. It's cool kids say that. So maybe I'll leave you with two questions. And the other panelists can continue to remain on the hot seat. So what are the cool applications? If there are eight, name all eight of them. If there are more that you have recently came to realization, please share them. And also maybe just share your definition of decentralization since we are at the Ethereum decentralization night and leave everyone here with an open challenge. Okay, so for applications, I think, you know, this is the year of caring about users, and so I'll name the last eight applications I actually used. So number, let's see, ENS, Polymarket, of course. Let's see, Railway. Just like ETH as a payments mechanism okay what else I guess I mean Farcaster yes five that's not an application that's a that's an L2 okay now I'm trying to think five I've I've, I mean, then there's the question of like, are swapping applications applications, or are they infra? Yeah. OK, let's like count them as an application. I think I'm trying to, OK, I'm trying to remember if I used like Uniswap or Cowswap or Kyber. I think ultimately I used the Rabi interface, and so I don't know. So one-third of a point for all three. Okay, that's number six. Wow, what else do I remember actually using? Gnosis. Which part? Gnosis Safe? Is that an application or is that infra? Okay, fine, it counts. Gnosis Safe, okay, that's also an application. And, okay, great, I need number eight. Wow, thanks, you guys are actually, like, that's not an application. Is Dogecoin an application? No. Okay, wow. It's like, now we're going to ask, like, are meme coins an application? Well, are they? Okay, so is, like, that last round of selling meme coins to pay for charity, like, is that an application? I don't know. Okay, that's number eight. Okay. Okay, so those are the eight. Okay, definition of decentralization. I think, I mean, when I think about decentralization, I generally think about, like, maximizing the number of independent things that have to fail for a system to break, right? And so, like, that thing, it could include, obviously, a number of different people that have to collude for a system to break it could even potentially include like geographics decentralization so number of countries that need to go crazy for a system to break or number of companies it could include number of software implementations so I think like number of software implementations. So I think number of things, especially number of uncorrelated things that need to break for your application to break is like the intuition pump, and you can get the different types of decentralization out for architectural, political, logical, and so on out from below that. And last one is a call to action. So I think mine is just like basically, like don't think about what is a mature space in 2024. Think about what is a new space in 2024. Think about what is in that same situation today that Plasma and Optimism and Uniswap were at back in 2018. What is in that same situation where nobody has any freaking proof that you can make profit off of it? It's something that still appeals to basically computer geeks and people who love math and people who love ideas. But something where if you make the right idea, it is something that is just this missing thing that could suddenly really bring the next level of power to the whole ecosystem and potentially create the next wave of problems. So figure out what it is. Hopefully avoid creating problems and go and battle it. Do you have any free gifts for unbuilt ideas? OK. I mean, as they say, gift is the German word for poison. So be careful with that one. Yes, you can check. Look it up. OK, actually, yeah. So OK, gifts. OK, so one category of idea that I think is interesting is, so back in 2018, there was this interesting, there was this like fun application that you could use where it was solving the problem of like getting people to sign up for meetups but like not having this situation where like 100 people sign up and only 30 people come and like you don't know how many people come. And the way that it worked is like basically you had to put down a deposit and it was like small deposit, like maybe 0.02 ETH to sign up. And then if you don't come, you lose your deposit. And if you do come, you get back your deposit plus a share of the deposits of people who didn't come, right? And like this actually got used and like basically people are like signing up for Ethereum meetups like actually became reliable. And I'm not sure why people ever stopped using it. It might have just been like crappy UX and crappy fees and problems that don't exist anymore in 2024. So I think that kind of idea is worth bringing back. Another class of idea, I think, is like what I call like multi-commitment mechanisms. So basically imagine like each individual person puts down a deposit, but they don't put down a deposit for one event. They put down a deposit for an entire class of events that they're willing to participate in. It could just be a list of events. It could potentially be something more complicated, like combinatorial academic fancy people can figure out the optimal version of this eventually, but you could just make it a list at the beginning. And then you could have people that propose events. And when they propose events, then, like, they would also specify a minimum number of people that would need to come. And then if there is an event that has enough people who have capital that, where they specify conditions that say that they're willing to participate, then all of their deposits get, like, yanked immediately, and then the event gets turned on and it happens. And so basically you have this very capital-efficient way to just very quickly gather up capital for arbitrary events. Could be meetups, could be pop-up cities, could be eventually building entire cities if we have another couple of bull runs. And basically allow this stuff to happen without requiring some centralized actor in the middle to take on all of the risk. So random fun idea. You figure out if it's like poison or if it's cool. I think it's cool. So enjoy. All right. Well, feel free to skittle, whatever that word is. But skedaddle. But oh, wait, Jing, you are not done because you're here to scale Ethereum. And, yeah, we have more questions. Yes. So we have more questions about scaling Ethereum for our optimism friends. So, you know, take a couple steps back. There's a really cool hipster application called Uniswap that Phil does not approve because of this concept of MEV back in the days. And rented as an advisor against building it, but then it was built. And then I saw MEV Auction as the defining early blog post. So how did all of this come together? Does anyone know where to start? I'm going to front run it to just say MEV Auction is hot again today. It is everywhere right now. I mean, it had a quiet moment, and it's the same reasons it offended me back then a little bit. I'm sorry, Carl. I love the idea. I just thought the execution was it could be a little more efficient in some ways. It's the same complaints I have with it now. So I'm, again, stuck in the same eight-idea loop. But I think that was a good one it was kind of like the idea of like okay if we do want to have this vision where the MEV is useful and it's not this purely negative thing and it's going to exist anyway how do we use it for something that's actually good or that we like or that like feels good and makes sense and maybe I'll let Carl and Jing speak to this. Actually, Phil hated it so much that FlashBoss exists now. Yay! So I mean, Meeva, as we wrote about it, is unimplemented. So what is it about the execution that you take issue with, and what have you done differently? Yeah, so I think the hard part is when you have an auction that's happening for something in the future, it's a very different market structure than like a mechanism that's expressing current real-time value as an oracle. It's like a very different set of actors that end up participating, and it's a very different like way you participate. And my thesis at the time was like it would be hard to like actually play this auction in a way that wouldn't be centralizing to basically the people who control this pot to be distributed, this kind of power in the system. Specifically, there's some recent posts that we have out of Flashbots about a priority auctions and the tradeoffs, how you price them, how that changes based on volatility, based on your signals, based on what kind of trader you are. It gets much more into those questions, which I felt at the time were not answered in a satisfying way for L2 or L1, versus I think the Flashbots philosophy was more like, let's accept some centralization because we need to build something that isn't just like a validator hedge fund, but let's try to get to this economic mechanism that gives us the properties we want, which is kind of this permissionless oracle for real-time MEV, where anyone can come in at any point in the process, whether or not they've won an auction, whether or not they've participated in a previous step, and kind of express their value if the system has time to process it. To me, that's like the holy grail of MEV mechanisms in action. And if you're excited about that, come see my DevCon talk tomorrow, because it will be featuring that and many other spicy takes. Did that answer the question, or was it unsatisfying? I mean, I have more questions, but maybe I should just go to your talk tomorrow. So I guess a couple more questions here. So why did you guys choose not to build Miiva back then? And like 2019, 20-ish? Well there was no value to extract yet. So we wanted to build the chain and then, like, put shit on it that you could use, and then there would be something valuable, and then Miva would be more of an issue. And turns out, building the chain infrastructure is actually really fucking hard. And so it's cool that you see all these chains popping up here and there today and that there's so many forks in different companies that are iterating on top of the OP stack with a different set of features or a different set of assumptions or a different proof system. But the fact that they can do that with the six month development cycle is because we did the six year development cycle, building that in the first place and MIT licensing it. So now the question is we're coming back into the zone, as Phil says, of discussing the same dumb ideas every eight months. But I think we make progress on the ideas every single time they do cycle back around. Yeah, maybe if my hair were longer, I'd have a more cynical take. But I think, you know, now there's value. And one thing that we didn't expect was that people kind of enjoy running their own sequencers. And so is that like a user research is really difficult to conduct because there's this kind of like sex appeal about running your own infrastructure. Like you show up to the conference and you're like, yeah, we run our own sequencer and people think you're cooler, genuinely, you know? So do people actually want to be running their own sequencers? When our customers propose new features, they're like, yeah, we want to change the size of the mem pool. And it's difficult to ask the seven levels of why to get to what they really want, which is almost always cheaper fees, more gas, faster transactions. And so, you know, previously we thought Miva would, you know, the assumption that Miva made was that all sequencing rights would kind of accrue in this big pool, like a Bitcoin mining pool, and, like, tons of different miners from all over the world, extractors from all over the world would come and bid on the rights to sequence out of this pool of computation demand. And we're not really sure if that's the case. Different chains want different sequencing policies. It's a lot of fucking work to build out a marketplace and nobody seems to need it quite yet. So that was quite a journey. Thanks for sharing that. So maybe just taking one step back, if I recall, Carl, when I first met you, you wouldn't stop ranting about the Internet government amongst many other, amongst many other things. Sometimes I forget that, yeah, that was a defining moment for me. And so, also, like, your rapping is just, like, you know, world class freestyle. That needs to happen at some time. But so what is really optimism scaling? Like, what is the reason why you're still building after so many years? And things are hard and challenging, and eight-month cycles and whatnot. I want to give this mic to Ben, because you have observed this dream or vision coming to life and still going, this journey. So the question is what are we all building for? I mean, there's a few levels of, you know, it depends on how AI doomer you are. If you take an extreme Carl stance, it's something like, we are in a race to align humanity before superintelligence comes owned by an unaligned human. So there's one answer at that level. I think maybe a more measured answer is that it's about solving the tragedy of the commons within the context of funding public goods. Jing told a lot of this story before about our early days and our struggles to work as a non-profit. And, like, that's just what we are. We were this little ragtag non-profit group. Like, hey, can you please donate some money and we'll produce, you know, good papers on EtherSearch. And it's very apparent that that doesn't scale. And, quite frankly, I think if you look at the... you you you you you you you you you you you you you you you you you you you you you",
"eventId": "devcon-7",
- "slot_start": 1731393000000,
- "slot_end": 1731393600000,
+ "slot_start": 1731397800000,
+ "slot_end": 1731398400000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1XmimA6xYE2Wr9c4tzpc9e9P7XDxysFx2QT8rBsA-piQ",
+ "resources_presentation": "https://docs.google.com/presentation/d/1usTBzr557w8yMObkzJBvScKjnAoHQFztqym-wk6b1dk",
"resources_slides": null,
"speakers": [
- "leo-lara"
+ "ya-wen-jeng",
+ "moven-tsai"
]
},
"vector": [
@@ -512769,9 +511677,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
+ 6,
6,
0,
0,
@@ -513064,6 +511970,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -513073,6 +511980,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -513106,9 +512014,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -513143,13 +512048,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -513415,6 +512318,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -513617,9 +512522,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -513635,25 +512540,37 @@
},
{
"session": {
- "id": "mood-rebalancing-singing-bowls-handpan",
- "sourceId": "SVAHJU",
- "title": "Mood Rebalancing (Singing Bowls + Handpan)",
- "description": "By Most Handpan X Ice\r\nThis session helps you feel emotionally centered and peaceful.\r\n- Bring balance to your emotions with singing bowls and handpan. \r\n- Using an emotion wheel, you’ll explore and understand your feelings, a key step to managing them. \r\n\r\nNov 15 10:30 - 11:15",
- "track": "Entertainment",
- "type": "Mixed Formats",
- "expertise": "",
+ "id": "mp-fhe-experiments-our-learnings-trying-to-find-the-next-big-tech-to-focus-on",
+ "sourceId": "9JYWVP",
+ "title": "MP-FHE experiments. Our learnings trying to find the next big tech to focus on.",
+ "description": "This talk mainly focuses on showcasing the work that some PSE members did while starting to dive into MPC-FHE during Q2 2024. This work is composed by various explorations within the MPC-FHE realm that move towards different directions and goals.\r\n\r\nFrom FHE compilers to FFT Bootstrapping GPU optimization proposals, passing by FHE Game demos and many application level implementations, the talk aims to reach beginner-advanced audience on the research/product paths that we have explored so far.",
+ "track": "Applied Cryptography",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "FHE",
+ "MPC",
+ "Explorations"
+ ],
+ "tags": [
+ "Homomorphic Encryption",
+ "Use cases of cryptography",
+ "exploration",
+ "Homomorphic Encryption",
+ "Use cases of cryptography"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "cperezz"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731641400000,
- "slot_end": 1731644100000,
- "slot_roomId": "decompression-room",
- "resources_presentation": "https://docs.google.com/presentation/d/1STERW4iF8WxYtoPJQKN2mZr5qwM1yuH_XYRcXEVM1pw"
+ "slot_start": 1731391800000,
+ "slot_end": 1731392400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/12k_WqxuHHHeL-ozPhNdmibpCzBNzvOlF-4z0chDHOyY"
},
"vector": [
0,
@@ -513665,16 +512582,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -514135,6 +513044,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -514440,6 +513350,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -514501,6 +513412,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -514829,6 +513741,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -514973,6 +513886,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -514991,72 +513905,48 @@
},
{
"session": {
- "id": "mood-uplifting-singing-bowls-handpan",
- "sourceId": "H7Y7L8",
- "title": "Mood Uplifting (Singing Bowls + Handpan)",
- "description": "By Most Handpan X Ice\r\nThis session fills you with positive energy, boosting your mood and clearing your mind.\r\n- Lift your spirits with the bright sounds of singing bowls, handpan, and soft percussion. \r\n\r\nNov 14 15:00 - 15:45",
- "track": "Entertainment",
- "type": "Mixed Formats",
- "expertise": "",
+ "id": "mpc-tooling-or-how-to-create-mpc-apps",
+ "sourceId": "QLMYBD",
+ "title": "MPC Tooling or How to create MPC apps",
+ "description": "Let's get into the state of the art of MPC development: we'll discuss different MPC schemes, current MPC tooling & how you can create MPC apps today.\r\nWe'll cover the tech stack from a frontend level (e.g. MPC compilers) to a backend - and of course how we can combine them.",
+ "track": "Applied Cryptography",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "tags": [
+ "Tooling",
+ "Cryptography",
+ "MPC",
+ "Cryptography",
+ "MPC",
+ "Tooling"
+ ],
+ "keywords": [
+ "Circom-MPC",
+ "MPC tooling"
+ ],
+ "duration": 489,
"language": "en",
- "speakers": [],
+ "sources_swarmHash": "8b8ee46fd9725a4ea9ca521e0da429005bef6925bc6bb11dae9ee6fc11c803aa",
+ "sources_youtubeId": "eKpcf1JMNak",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f7f280d989c5b7abc08b.vtt",
+ "transcript_text": " Hi everyone, my name is Rasul. I work in MPC research team of privacy and scaling explorations. And today I want to talk about MPC tooling or how we can create MPC apps. So what exactly I'm going to go over is like first short introduction, what is MPC? Then I'm going to talk about applications of MPC and then I'm going to talk I'm going to cover tools we work on in our team that allow people to create MPC apps and then short example interesting example of using these tools. So what is MPC? MPC is an interactive protocol that allows parties to jointly compute a function or their inputs while keeping those inputs private. So let's imagine that we have a public function f that takes two parameters, x and y. And let's say party one provides x parameter, party two provides y parameter, and they will be able, parties will be able to compute the output of this function while keeping their individual inputs private. So there are two kinds of MPCs. First one is app-specific and second one is general purpose MPC. So app-specific protocols, MPC protocols are designed to represent one specific function. So let's say threshold signatures, Shamir secret sharing and PSI and many others. And general purpose are designed to represent any function including the all the app specific protocols as well. So there are many applications of MPC. I'm going to mention a few examples. So it's like privacy preserving, preserving machine learning, cost narcs, MPC stats is another great project that PSTM works on, and etc. So first tool I want to talk about is called Circum MPC. Circum MPC is basically a project, a project is a fork of Circum, it's a famous ZK DSL, but it compiles to a universal MPC format called Bristol Fashion Circuit, that can describe Boolean and arithmetic circuit. So why we chose Sercom is because many zk slash cryptography devs already know Sercom and it will be easier for them to create circuits in Sercom. And there's also a big number of circuits written in Sercom already. For example, SercomLibML. And they can be reused without changing the code. And that's actually what we did in PSE as well. We just took circumlibml, Kathy's library, and we were able to run MPC circuits, ML, sorry, in MPC. Another tool I want to talk about is called Summon. Summon is a language for collaboratively summoning computations. And it's another tool that my teammate mostly works on, Andrew Morris, and summon is TypeScript like DSL, similar to Circum NPC, with a goal for user-friendliness. It can be used from or in TypeScript, and therefore it allows to build everything end-to-end in TypeScript. So if you know Cursive Team, they already use a summon tool as well in their apps. And the last tool I want to cover is called CircumMPSpeeds. So first of all, MPSpeeds itself is a big, big framework that people can use to create NPC apps. But it might be a bit hard for beginners to start with it. So what we do, so Circum MPC speeds is basically a transpiler from Bristol format that generated by someone compiler by Circum MPC, and a transpiler from Bristol format to .mpc representation that is required to run the circuit in MPC with MPSpeed's backend. And this project shows an example of running circum-libml machine learning circuits in MPSpeed. And you can find benchmarks and every information about this in the repo. And yeah, as I said, the same tool can be used to transpile circuits generated by someone as well, not only by circum NPC and The last thing I want to talk about is an example of using these tools specifically someone It's a matching game for friends and lovers That Barry Whitehead was talking about last year on Def Connect Istanbul. It's called two PCs for lovers So basically you can play with your friends or with your lover and you can choose love. But if you choose love but the result is friendship, only you will know about your feelings. Even if your friend knows advanced cryptography. And you can try it here. Yep. That's it. Thanks for coming. You can find me by my username, Kairisu. Yep. Thank you, Rizu. Any questions? Oh, there's one. I probably need some help. No. Do you want to try? Yeah, let's go. I'll leave my mic here. There? Sorry. Sorry, Georgi. That was a good direction, so. Okay. I have a question. Did you explore using MPC for building interoperability on bridges? No, actually. No, I don't think so. I don't think so, no. Do you have an idea? Like, for example? Opinion? Yeah, I mean, building interoperability protocols with MPC. No, we weren't doing this. We mostly were focusing with... I work mostly on Circum NPC. So we were focusing on privacy-preserving machine learning. Like, mostly. And, yeah. Not on that case yet. Yeah, sure. I mean, we are just exploring it and getting into it. So I wanted to see more opinions and build our surround that. Okay, thanks. Sorry if I didn't answer it. We see a question over there. Oh, this is a mic. Sorry, I didn't know this was a mic. Siracom usually targets an R1CS backend, and so I'm assuming all of these other tools also. And my question is, do you pay a price for that? Are there other MPC arithmetizations that you work with? Or is there something inherently related to the Seracom toolchain that you find useful here? Sorry, your question is, do we have? So my question is that, sorry. Oh, okay, sorry. I was not here when the DICE was introduced. But my question is that SIRCOM is typically targeting an R1CS backend, and so I'm assuming all these frameworks and toolings are doing the same, but there are some pretty clever other arithmetizations, and I'm wondering if MPC is solely in this domain, or you can make use of other things like Plonk or other repetitions? Yeah, I think it's like, as I mentioned, we like, it's a fork of Sercom, and we don't target R1CS, instead we target Bristol format. Bristol format is a universal MPC format that can describe arithmetic and Boolean circuit, and yeah, it's just like a super simple format, and from this format you universal MPC format that can describe arithmetic and Boolean circuit and Yeah, it's just like a super simple format and from this format You can already I don't know also transpile it to whatever back-end you want So for example MPC library is like another library that PC works on you can target this library You can speak target MP speeds library. Yeah, etc Let's give a big applause to resume",
"eventId": "devcon-7",
- "slot_start": 1731571200000,
- "slot_end": 1731573900000,
- "slot_roomId": "decompression-room",
- "resources_presentation": "https://docs.google.com/presentation/d/1vnIacRdbAcvTa2ioFdaqS_vlSqjDw2GnNcAukvszKyw"
+ "slot_start": 1731390600000,
+ "slot_end": 1731391200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1F2EhWXcgf32_Gh77ty0p18d2rnEPMZymHL7KX7iwSdE",
+ "resources_slides": null,
+ "speakers": [
+ "rasul-ibragimov"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -515067,6 +513957,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -515528,6 +514419,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -515817,6 +514709,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -515824,6 +514717,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -515891,6 +514785,43 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -516329,6 +515260,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -516347,47 +515279,53 @@
},
{
"session": {
- "id": "mopro-make-client-side-proving-on-mobile-easy",
- "sourceId": "BZWFEM",
- "title": "Mopro: Make Client-side Proving on Mobile Easy",
- "description": "Mopro is a toolkit for ZK app development on mobile. Mopro makes client-side proving on mobile simple. Mopro aims to connect different adapters with different platforms. In this talk, we will share:\r\n- How to use Mopro to develop your own ZK mobile app.\r\n- What is the current development progress, including the current supported proving systems, supported platforms, and mobile GPU exploration results. \r\n- Moreover, we will share the challenges that Mopro faces and our future roadmap.",
+ "id": "mpcstats",
+ "sourceId": "ND3S9R",
+ "title": "MPCStats",
+ "description": "MPCStats is a framework allowing data consumers to query statistical computation from either one or multiple data providers while preserving privacy to those raw data. We support standard statistical operations, including nested and filter ones. Data providers do not leak their data and data consumers can be convinced the computation is done correctly.",
"track": "Applied Cryptography",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"tags": [
- "ZKP",
- "Cryptography",
- "Mobile",
- "android",
- "Cryptography",
- "Mobile",
- "ZKP"
+ "Tooling",
+ "Privacy",
+ "MPC",
+ "Public good",
+ "verification",
+ "computation",
+ "MPC",
+ "Privacy",
+ "Public good",
+ "Tooling"
],
"keywords": [
- "iOS",
- "Android"
+ "privacy-preserving",
+ "data analysis",
+ "MPC",
+ "statistics",
+ "verifiable computation"
],
- "duration": 958,
+ "duration": 508,
"language": "en",
- "sources_swarmHash": "83f2fcfab64a4052bdaa28b2c9f33ae4f5a4bccdd8fdc70865019c8ab568a649",
- "sources_youtubeId": "0ziKiYwhJHk",
+ "sources_swarmHash": "9b8211a5308190cf41598cd33cefed8af79e239f4d4c5a6648a32a2cbcf77f51",
+ "sources_youtubeId": "wCp7Zsjou7w",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673309f83a168eb535ebd6e0.vtt",
- "transcript_text": " A scaling research perspective. Yeah, so we had raised, well, first we were supposed to write the book on Plasma. And every single time, remember I was a Bitcoiner transitioning into the Ethereum world. And every single time I finished writing a chapter, the research space had progressed enough that I would have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got have to delete the chapter and rewrite it. And then five rewrites later, I was like, this is not what I got paid to do. Five rewrites later, we were like, wait, this is definitely an implementable design. So we implemented it, we published it, we launched a test net, we got all these likes on Twitter. I remember we had 1,000 likes. I remember screenshotting it to my parents and sending it to them. And it wasn't the same as product market fit. And so, you know, after like three months of our Plasma network, I was like, we've done it. We've scaled Ethereum. Why isn't everyone cheering? Why isn't mass adoption coming? And there had been a total of, I think, four transactions on the test network. And all four of them were our transactions. So after that, we went back to the drawing board, and we hit up some people at a firm called IDEO. And they introduced us to the concept of talking to your users. And it explains a lot about crypto. This is like a year into the development of Plasma. So for the very first time, we spoke to some users, and we said, we've got theoretically infinite transactions per second. You just have to adopt this completely new Plasma predicate system, and you have to learn a new programming language, which we've just invented. And people were like, you know, I actually don't want to do that. I'm a product manager at Coinbase and I've got a lot of shit to do and I'm not going to rewrite all my contracts. We're like, okay, Uniswap. Uniswap should be simple enough. And Hayden was like, bro, my shit is 100 lines of code. I'm not about to rewrite that shit in a brand new language. I'm doing just fine. My users are just fine paying the fees. And so we realized that what we had built was not actually what people wanted. There wasn't enough usage in crypto at the time to warrant having theoretically infinite TPS. What people wanted was cheap transactions and fast transactions. A single transaction averaged anywhere between $5 and $25 depending on what was happening. So we went back to the drawing board. But the only problem was I had raised a total of $300,000 in grant funding. And it was enough to pay each of us like $40,000. Our office was my studio apartment in New York City. I lofted my bed. Everything under my bed was like my room, and we shared one Ikea table. And it turns out if you have kids, so like if you have any experience doing any kind of work, you didn't want to work for us. And I remember offering a very senior staff engineer $120,000 a year because I thought that that was a lot of money. And he was like, no, I'm thinking like $250,000, and that was crazy to me. So tried to raise another round of grant funding. Didn't work, which was surprising to us because Omise Go, this company that had raised $30 million in ICO funding, didn't want to give us more money. The other projects that had forked our code base, including Matic, which is today Polygon, also didn't want to give us grant funding. So how could it be? Did nobody want what we were building? So we went back to the drawing board and built out a demo of the first optimistic rollup with Uniswap. The idea was we needed one-click deploy. TPS was not the optimization target. We were optimizing for fast transactions, cheap transactions. And we demoed that, and we went and raised a round of VC funding. VCs were like, how are you planning to monetize? No idea, but all I knew was we needed to start hiring more than just four half-brained kids who didn't even have their frontal cortex fully developed and have never heard of a product manager before. And that's where we are now today, four years later. Yeah, I mean, I think the way that I saw the research side of this, right, is basically that in the beginning, there were state channels. Actually, Bitcoin came up with state channels first. It was just called payment channels, and then it was called the Lightning Network. And it turns out that the Lightning Network has a lot of problems. But then state channels in Ethereum, thanks to Ethereum smart contract properties, were more powerful. But even still, there is this problem that they only supported a very narrow class of applications. And then in 2017, Plasma came along, and Plasma actually supported arbitrary scale, scalability for payments. And so at first, there was Joseph Poon's paper back in the summer. Then there was Minimal Viable Plasma, which is a post on ETH Research. And then Carl and I, I think on a train in France, came up with Plasma Cash, which is like Plasma but more scalable, right? Because like Bitcoin Cash is like Bitcoin but more scalable. And so, but then even that still, like it only supported payments, right? And then we went into this rabbit hole of like using RSA and like cryptography. And then we did plasma prime but then eventually we got like to this point where we realized that like with the technology at the time actually plasma just could not be made to be general-purpose and that just became more and more obvious and then at some point like basically the idea of roll-ups so started to come out and like people just realized that doing a roll-up that actually supports a full EVM was actually the obvious choice and what I think is interesting right is like I think short term like that was completely true right because there was also this other project from 2020 called Loopring that did a ZK rollup using, that was like fully functional, like even got to stage two very quickly, very cheap, but then nobody cared because people did not want payments, people wanted the EVM. And so then stuff switched to the rollup direction. And then more recently we realized like, wait, ZK-SNARKs exist, they're amazing. And like actually there's, with ZK-SNARKsnarks there's a lot of plasma stuff that you can do that was not actually possible before. So like I actually think there's a good possibility that in a couple of years things are gonna go like fully full circle. Oh and one foot as you could tell V was like kind of behind the scenes like doing all these things and one thing one thing I remember, I was in a car, and I was like, wait, so if you post the data in the call data, it saves X amount of money. And then Vitalik was like, oh, that sounds like Shadowchains, this thing that I wrote about in 2014. Anyway, it was a whole weird melting pot of ideas and things that all, you know, now we're here. Personally, I feel like the entire industry is doomed to talk about the same like six ideas on like an eight month loop to infinity. Maybe I'll be convinced that I'm wrong in a few years, but this is my current thesis. So just trolling a little bit. Yeah. Well, so I think switching gear a little bit, since Hayden cannot make it here, Uniswap also has a really interesting story like Carl mentioned. But it may be one of the earliest and most usable applications. And there's a lot of MEV in there. There's a lot of how to build an application on Ethereum. Like I would say lessons learned. So yeah, maybe I'll give it to V first because he's, yeah, I guess. Sorry, what's the question? Okay. Okay, I'll grab it. Basically, I mean, there is a untold Uniswap side of the story, which I told Hayden that I would also do, so I feel obligated to answer your question. I hope you don't mind. Which is that Hayden also was behind the scenes talking about this. And I talked about this in a presentation, DevCon 4 or whatever. But basically, I remember many times we were in Brooklyn with Hayden, with the Uniswap team, going to their office saying, hey, check out our new design. It's so scalable and it's so great. And as Jing said, it was a predicate design or whatever. And then Hayden was like, okay, but can it support Uniswap? And the answer was, no, it cannot. And we went through design after design after design after design. And eventually we finally, finally came to this you know to the optimistic role of design which actually could support Uniswap and so Hayden and really the Uniswap team has been like you know very much you know kind of a guy a guiding light for what it means to build a successful application because Uniswap is a successful application that has users. Surprise, surprise. Not like our plasma design. Anyway. Yeah. I mean, one other fun thing about Uniswap is I think there's this, like, other even deeper rabbit hole where the ideas came from, right? Which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right, which is the whole theory of automated market makers, which before was actually, like, backported from prediction markets, right? So basically what happened was that people were thinking about prediction markets all the way since, like, the 1980s and 90s. And then one problem that they faced is, like, situations where they wanted the market to stay liquid even in the face of, like, relatively few users. And they wanted a way for people who are publicly interested in learning the outcome and willing to pay for it, a way to subsidize the market. And so out of that, there were these ideas that were called market scoring rules that were basically like the equivalent of making an infinite number of infinitesimal bids and asks at every price level, right? And if you actually do the math on this, this just converts into very basic functions. There's one that's called the logarithmic market scoring rule. There's one called the quadratic scoring rule. And I knew about these because I was a prediction market fan. And then at some point, this idea clicked and I wrote this Reddit post that basically said, let's run on-chain decentralized exchanges the way that we run prediction markets. And the idea there was, well, there were on-chain DEXs before. They used order books. They had horrible spreads. They were ugly to use. And so let's, like, use this idea of, like, just having an on-chain curve that you can, like, buy and sell along and let's figure out the curve. And then I wrote this post and then about six months later I wrote another post basically defending why you can't like drain the thing of money and then about a year later like basically Haydn came along and like that actually yeah became implemented right and then of course since then like those this and then prediction markets themselves turn into designs where like you just issue tokens and you just have an AMM between tokens so like everything went full circle multiple times I'm sorry I got too markets themselves turn into designs where you just issue tokens and you just have an AMM between tokens. So everything went full circle multiple times. I'm sorry, I got too excited. But just as all good ideas are recycled, the good idea of building an X times Y equals K market maker was really Vitalik being like, Carl, this is very obviously something that needs to be built, and no one is building this idea that I have. And I'm like, oh, well, I happen to have someone, as you said, who's right there for it. So anyway, good old me. I was actually very offended by the early Uniswap designs, because I was like, oh, my God, these people, they want their kind of libertarian like info prediction market so bad that they're not thinking about the consensus consequences of exposing all this MEV and what it's going to do to validators, stake centralization over time, kind of concentration to places like Wall Street. And I sent Vitalik like a super angry rant. It might have even been all caps. I don't have it anymore because I used to run my own email server and that got nuked by a third tier VPS provider. But that's its own rant. But I was like, wow, this is horrible for a consensus. How can we advocate this design? This is literally unlimited MEV per block. The entire liquidity, the entire order flow, it's like, it could not be worse. Can't we do something more like the EtherDelta design with a little limit kind of system, maybe an off-chain component? It's not great. It's a little more centralized, but it's at least how we know how to solve the problem right now. And it doesn't expose infinite MEV the way this design was. And I think Vitalik sent back one line. He was like, well, we can maybe just consider this fees for users to have their transactions executed. And I was super offended. I was like, what do you mean fees? Like, how do you extract this? How do you, like, blah, blah, blah, blah, blah. And I think now what we have in production is Uniex, which in some ways was, like, my original suggestion to them to what to do instead. When they launched it, I was like, what are you doing? Like, you finally fixed all the problems with, like, the old design. It's finally convinced, like, me that it's the right thing. And now you're going back. Like, so, yes, TLDR, I do feel like we're just circling, like, the same four things. We're probably going to see permissionless AMMs come back at some point. This is kind of like a call to the room in various settings, this is my opinion, that are kind of even decoupled from L2s completely. So sorry, optimism, but it's going to be both. So that's my trolling today. Yeah, so, well, speaking of things going back in circles, that Robin Henson today just, or these past 48 hours just launched a prediction market on aetherium right it's kind of crazy and to think about how the real world is you know impacted well I guess we are in the real world. So speaking of that, I know Vy needs to bounce at some point. Skedaddle. I have no idea what that is. OK. It's cool kids say that. So maybe I'll leave you with two questions. And the other panelists can continue to remain on the hot seat. So what are the cool applications? If there are eight, name all eight of them. If there are more that you have recently came to realization, please share them. And also maybe just share your definition of decentralization since we are at the Ethereum decentralization night and leave everyone here with an open challenge. Okay, so for applications, I think, you know, this is the year of caring about users, and so I'll name the last eight applications I actually used. So number, let's see, ENS, Polymarket, of course. Let's see, Railway. Just like ETH as a payments mechanism okay what else I guess I mean Farcaster yes five that's not an application that's a that's an L2 okay now I'm trying to think five I've I've, I mean, then there's the question of like, are swapping applications applications, or are they infra? Yeah. OK, let's like count them as an application. I think I'm trying to, OK, I'm trying to remember if I used like Uniswap or Cowswap or Kyber. I think ultimately I used the Rabi interface, and so I don't know. So one-third of a point for all three. Okay, that's number six. Wow, what else do I remember actually using? Gnosis. Which part? Gnosis Safe? Is that an application or is that infra? Okay, fine, it counts. Gnosis Safe, okay, that's also an application. And, okay, great, I need number eight. Wow, thanks, you guys are actually, like, that's not an application. Is Dogecoin an application? No. Okay, wow. It's like, now we're going to ask, like, are meme coins an application? Well, are they? Okay, so is, like, that last round of selling meme coins to pay for charity, like, is that an application? I don't know. Okay, that's number eight. Okay. Okay, so those are the eight. Okay, definition of decentralization. I think, I mean, when I think about decentralization, I generally think about, like, maximizing the number of independent things that have to fail for a system to break, right? And so, like, that thing, it could include, obviously, a number of different people that have to collude for a system to break it could even potentially include like geographics decentralization so number of countries that need to go crazy for a system to break or number of companies it could include number of software implementations so I think like number of software implementations. So I think number of things, especially number of uncorrelated things that need to break for your application to break is like the intuition pump, and you can get the different types of decentralization out for architectural, political, logical, and so on out from below that. And last one is a call to action. So I think mine is just like basically, like don't think about what is a mature space in 2024. Think about what is a new space in 2024. Think about what is in that same situation today that Plasma and Optimism and Uniswap were at back in 2018. What is in that same situation where nobody has any freaking proof that you can make profit off of it? It's something that still appeals to basically computer geeks and people who love math and people who love ideas. But something where if you make the right idea, it is something that is just this missing thing that could suddenly really bring the next level of power to the whole ecosystem and potentially create the next wave of problems. So figure out what it is. Hopefully avoid creating problems and go and battle it. Do you have any free gifts for unbuilt ideas? OK. I mean, as they say, gift is the German word for poison. So be careful with that one. Yes, you can check. Look it up. OK, actually, yeah. So OK, gifts. OK, so one category of idea that I think is interesting is, so back in 2018, there was this interesting, there was this like fun application that you could use where it was solving the problem of like getting people to sign up for meetups but like not having this situation where like 100 people sign up and only 30 people come and like you don't know how many people come. And the way that it worked is like basically you had to put down a deposit and it was like small deposit, like maybe 0.02 ETH to sign up. And then if you don't come, you lose your deposit. And if you do come, you get back your deposit plus a share of the deposits of people who didn't come, right? And like this actually got used and like basically people are like signing up for Ethereum meetups like actually became reliable. And I'm not sure why people ever stopped using it. It might have just been like crappy UX and crappy fees and problems that don't exist anymore in 2024. So I think that kind of idea is worth bringing back. Another class of idea, I think, is like what I call like multi-commitment mechanisms. So basically imagine like each individual person puts down a deposit, but they don't put down a deposit for one event. They put down a deposit for an entire class of events that they're willing to participate in. It could just be a list of events. It could potentially be something more complicated, like combinatorial academic fancy people can figure out the optimal version of this eventually, but you could just make it a list at the beginning. And then you could have people that propose events. And when they propose events, then, like, they would also specify a minimum number of people that would need to come. And then if there is an event that has enough people who have capital that, where they specify conditions that say that they're willing to participate, then all of their deposits get, like, yanked immediately, and then the event gets turned on and it happens. And so basically you have this very capital-efficient way to just very quickly gather up capital for arbitrary events. Could be meetups, could be pop-up cities, could be eventually building entire cities if we have another couple of bull runs. And basically allow this stuff to happen without requiring some centralized actor in the middle to take on all of the risk. So random fun idea. You figure out if it's like poison or if it's cool. I think it's cool. So enjoy. All right. Well, feel free to skittle, whatever that word is. But skedaddle. But oh, wait, Jing, you are not done because you're here to scale Ethereum. And, yeah, we have more questions. Yes. So we have more questions about scaling Ethereum for our optimism friends. So, you know, take a couple steps back. There's a really cool hipster application called Uniswap that Phil does not approve because of this concept of MEV back in the days. And rented as an advisor against building it, but then it was built. And then I saw MEV Auction as the defining early blog post. So how did all of this come together? Does anyone know where to start? I'm going to front run it to just say MEV Auction is hot again today. It is everywhere right now. I mean, it had a quiet moment, and it's the same reasons it offended me back then a little bit. I'm sorry, Carl. I love the idea. I just thought the execution was it could be a little more efficient in some ways. It's the same complaints I have with it now. So I'm, again, stuck in the same eight-idea loop. But I think that was a good one it was kind of like the idea of like okay if we do want to have this vision where the MEV is useful and it's not this purely negative thing and it's going to exist anyway how do we use it for something that's actually good or that we like or that like feels good and makes sense and maybe I'll let Carl and Jing speak to this. Actually, Phil hated it so much that FlashBoss exists now. Yay! So I mean, Meeva, as we wrote about it, is unimplemented. So what is it about the execution that you take issue with, and what have you done differently? Yeah, so I think the hard part is when you have an auction that's happening for something in the future, it's a very different market structure than like a mechanism that's expressing current real-time value as an oracle. It's like a very different set of actors that end up participating, and it's a very different like way you participate. And my thesis at the time was like it would be hard to like actually play this auction in a way that wouldn't be centralizing to basically the people who control this pot to be distributed, this kind of power in the system. Specifically, there's some recent posts that we have out of Flashbots about a priority auctions and the tradeoffs, how you price them, how that changes based on volatility, based on your signals, based on what kind of trader you are. It gets much more into those questions, which I felt at the time were not answered in a satisfying way for L2 or L1, versus I think the Flashbots philosophy was more like, let's accept some centralization because we need to build something that isn't just like a validator hedge fund, but let's try to get to this economic mechanism that gives us the properties we want, which is kind of this permissionless oracle for real-time MEV, where anyone can come in at any point in the process, whether or not they've won an auction, whether or not they've participated in a previous step, and kind of express their value if the system has time to process it. To me, that's like the holy grail of MEV mechanisms in action. And if you're excited about that, come see my DevCon talk tomorrow, because it will be featuring that and many other spicy takes. Did that answer the question, or was it unsatisfying? I mean, I have more questions, but maybe I should just go to your talk tomorrow. So I guess a couple more questions here. So why did you guys choose not to build Miiva back then? And like 2019, 20-ish? Well there was no value to extract yet. So we wanted to build the chain and then, like, put shit on it that you could use, and then there would be something valuable, and then Miva would be more of an issue. And turns out, building the chain infrastructure is actually really fucking hard. And so it's cool that you see all these chains popping up here and there today and that there's so many forks in different companies that are iterating on top of the OP stack with a different set of features or a different set of assumptions or a different proof system. But the fact that they can do that with the six month development cycle is because we did the six year development cycle, building that in the first place and MIT licensing it. So now the question is we're coming back into the zone, as Phil says, of discussing the same dumb ideas every eight months. But I think we make progress on the ideas every single time they do cycle back around. Yeah, maybe if my hair were longer, I'd have a more cynical take. But I think, you know, now there's value. And one thing that we didn't expect was that people kind of enjoy running their own sequencers. And so is that like a user research is really difficult to conduct because there's this kind of like sex appeal about running your own infrastructure. Like you show up to the conference and you're like, yeah, we run our own sequencer and people think you're cooler, genuinely, you know? So do people actually want to be running their own sequencers? When our customers propose new features, they're like, yeah, we want to change the size of the mem pool. And it's difficult to ask the seven levels of why to get to what they really want, which is almost always cheaper fees, more gas, faster transactions. And so, you know, previously we thought Miva would, you know, the assumption that Miva made was that all sequencing rights would kind of accrue in this big pool, like a Bitcoin mining pool, and, like, tons of different miners from all over the world, extractors from all over the world would come and bid on the rights to sequence out of this pool of computation demand. And we're not really sure if that's the case. Different chains want different sequencing policies. It's a lot of fucking work to build out a marketplace and nobody seems to need it quite yet. So that was quite a journey. Thanks for sharing that. So maybe just taking one step back, if I recall, Carl, when I first met you, you wouldn't stop ranting about the Internet government amongst many other, amongst many other things. Sometimes I forget that, yeah, that was a defining moment for me. And so, also, like, your rapping is just, like, you know, world class freestyle. That needs to happen at some time. But so what is really optimism scaling? Like, what is the reason why you're still building after so many years? And things are hard and challenging, and eight-month cycles and whatnot. I want to give this mic to Ben, because you have observed this dream or vision coming to life and still going, this journey. So the question is what are we all building for? I mean, there's a few levels of, you know, it depends on how AI doomer you are. If you take an extreme Carl stance, it's something like, we are in a race to align humanity before superintelligence comes owned by an unaligned human. So there's one answer at that level. I think maybe a more measured answer is that it's about solving the tragedy of the commons within the context of funding public goods. Jing told a lot of this story before about our early days and our struggles to work as a non-profit. And, like, that's just what we are. We were this little ragtag non-profit group. Like, hey, can you please donate some money and we'll produce, you know, good papers on EtherSearch. And it's very apparent that that doesn't scale. And, quite frankly, I think if you look at the... you you you you you you you you you you you you you you you you you you you you you",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733041280d989c5b7bfec34.vtt",
+ "transcript_text": " Hello everyone. So we're MPC's stats team at BSC. So today we'll introduce our project, and it's currently worked on by Jern and I and Kazumune. So the goal of our project is to build a framework that allows users to query statistical computation across different data providers. We'll guarantee the data privacy and also the correctness of the result. We've implemented common statistical operations using MP-SPEEDS, which is a well-known MPC framework. We've supported 12 statistical operations, and also some common table join and array concatenation and filtering. So users can define computation like this. And we also integrated TLS notary so that the inputs to MPC are authenticated from some well-known websites so that we can prevent garbage in, garbage out situation. All right, thank you, Kevin. So basically, right now, we are talking about MPC, right? So intuitive approach for MPC is that having all parties, data providers, data consumers, to join as a competition parties, right? The bad things, I mean, the good thing for us, let's say, is that it's free verifiability because everyone is in the same, like, competition set, right? So they know, like, what competition is done, right? I request mean, I know that this guy just compute mean for me, right? The bad thing is that the data providers, consumers, everyone need to be online at the same time. And it's really hard, right, for many numbers of data providers, especially when the number of data providers grows, the computations grow skyrocket so badly. So how to solve that, right? We use another approach called client interface, which basically means that the data providers and data consumers are not in the computation parties. So there's three phases. The first phase is that data providers secretly share the data through some delivery links. They can log in, share data, and log out. And then another set of computation parties compute data, and once it's ready, data consumers just log in to get it out. So this is good because now the data provider and consumer doesn't need to be online at the same time, which makes sense. And it also doesn't grow with the number of data provider because the cost of the MPC computation is actually from the number of the parties in the computation parties. The bad thing is that the data providers and consumer now need to trust the parties, right? It depends on our setup. If it's malicious, we need to trust at least one of the parties is right. And again, because we are not joining in the NPC computation party itself, we have no idea what is the function that they calculate is actually the one we want. But again, the trust assumption is the same. If you trust that at least one of the malicious setting of the computation party is honest, we can be sure that they just run the computation that we want, like mean or median or anything we want. So use case, we are thinking about cross-department data sharing government, verifiable salary data, any survey research for policy planning. And yeah, many more, let us know. So demo time. So this is really up and running. We're still under maintenance, final optimization, because it's pretty big. So we will notify soon. But it's pretty interesting to explore ETH balance inequality at DEF CON. So what it means, you guys can use your Binance to share it privately. We won't know your Binance balance, but then we will be able to calculate the interesting stats we will show later. But you guys should join this group first. So we will notify by today, tomorrow, once the Docker file is smaller so that it can make sense to run in this internet, in DevCon. So the caveat, right, because we want to be upfront, so we will only allow you to share privately the free in-your-spot balance of Binance. And again, the parties could still learn the number of digits, although this comes from the limitation over here. It's not itself that the parties still know the number of digits of your finance balance but again we won't know actually the number and again this is the trust assumption that we trust that our three party doesn't collude right and please please join this telegram group we will get a bit soon and anyone who join will get a chance to win an NFT and win a lottery as an actual cash so yeah so this is just a quick go through it will already be in our readme, in our demo. So, get Binance API key, just go, yeah, Binance API key. Everyone knows how to do that. Get the API key and secret key. Make sure it's read only. And then, yes, so notarize this. This is only our script that you need to run. You just get clone and each address is just address for receiving the price. This is not the address for the Binance. This is just to send the price if you want one. And yeah, this is the website. So we are having max ETH balance of DEFCON, mean, median, number and Gini coefficient to make sure of the inequality. So yeah, join us. Thank you so much. Thank you, Kevin, John. Any questions? Oh, that's too far. Okay, you got it. Hey, great talk. It's not clear to me. Are you guys trying to collect aggregate statistics from multiple parties? And if that's the case and that's the use case, it's not clear to me, are you guys trying to collect aggregate statistics from multiple parties, and if that's the case and that's the use case, did you explore something like a Brio-like system, using function secret sharing? I don't think MP Speed supports that, so I'm kind of curious. It should be much, much more efficient. Yeah, thank you so much for the suggestion. Yeah, I think we've looked through some of it, but this limitation mostly is through the number of data providers. So, right now, again, like FHG, multi-key, functional encryption, secret string, yeah, we looked through some of them, and we're thinking of using some, but again, the limitation right now is that the state-of-the-art MPC of a huge number of provider, it still matters. And we think again, because we make sure that we don't want the competition to just grow indefinitely with the number of data providers, so we still use this. But thank you so much. Yeah, so just look at function secret sharing. I think it would really, really boost your results. Thank you. I appreciate function secret sharing. Note. Do we have any other questions? Oh, there's one. Hi, I was trying to scan the TG QR code that you showed just now, and it says link expired for me. Is it just t.me slash NPC stats as a link? Yes, yes. Okay. Sorry about this. So t.me slash NPC stats. Any other question? Can I ask a question? I know that the federated learning is similar to preserving privacy and then the medical hospitals, they're having a lot of confidential data of the patients, so they use federated learning. I just wonder what you're presenting, how different it is from federated learning. Yeah, so basically federated learning is like you train offline, right? Like data is still there, and then you send the update on the gradient descent or anything to your machine learning app in the air, right? So basically you train everything up there. But now, MPC, it means that you gather data from different parties and compute at the same time. So for federated learning, it can just actually, it depends on what types of things you use, but it can also use MPC itself So but yeah when it comes to fit running people still consider like not too many parties or at once But when we are thinking about stats, we are thinking about like population So we wish to make it more scalable into a number of data providers itself But yes, I think a lot of federated learning techniques to use MPC But we just want to make sure that MPC framework that really scalable to a huge number of data providers. Yes. Okay. Thank you",
"eventId": "devcon-7",
- "slot_start": 1731397800000,
- "slot_end": 1731398400000,
+ "slot_start": 1731396000000,
+ "slot_end": 1731396600000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1usTBzr557w8yMObkzJBvScKjnAoHQFztqym-wk6b1dk",
+ "resources_presentation": "https://docs.google.com/presentation/d/10sZNPm9ETDOiRts7vDo9aVWovdRE2PpqvKAxR6_9Lv8",
"resources_slides": null,
"speakers": [
- "ya-wen-jeng",
- "moven-tsai"
+ "kevin-chia",
+ "teeramet-jern-kunpittaya"
]
},
"vector": [
@@ -517156,11 +516094,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -517218,8 +516151,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -517236,6 +516167,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -517255,12 +516187,14 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -517490,6 +516424,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -517505,7 +516440,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -517564,6 +516498,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -517708,9 +516643,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -517726,42 +516661,45 @@
},
{
"session": {
- "id": "mp-fhe-experiments-our-learnings-trying-to-find-the-next-big-tech-to-focus-on",
- "sourceId": "9JYWVP",
- "title": "MP-FHE experiments. Our learnings trying to find the next big tech to focus on.",
- "description": "This talk mainly focuses on showcasing the work that some PSE members did while starting to dive into MPC-FHE during Q2 2024. This work is composed by various explorations within the MPC-FHE realm that move towards different directions and goals.\r\n\r\nFrom FHE compilers to FFT Bootstrapping GPU optimization proposals, passing by FHE Game demos and many application level implementations, the talk aims to reach beginner-advanced audience on the research/product paths that we have explored so far.",
- "track": "Applied Cryptography",
- "type": "Lightning Talk",
+ "id": "mud-how-we-built-an-evm-application-framework-from-the-ground-up",
+ "sourceId": "883QBY",
+ "title": "MUD - How we built an EVM application framework from the ground up",
+ "description": "We wanted to accomplish one simple task: put a game—with all its data and logic—on a blockchain. What followed were countless technical challenges, years of efforts, and learnings that are applicable to anyone building complex onchain apps.\r\n\r\nHow should data be structured? How can complex world state stay up-to-date on the client? How do we allow multiple teams to build on one single world, without it all breaking apart? Join us as we share the pitfalls and learnings.",
+ "track": "Developer Experience",
+ "type": "Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "FHE",
- "MPC",
- "Explorations"
+ "Onchain",
+ "Games"
],
"tags": [
- "Homomorphic Encryption",
- "Use cases of cryptography",
- "exploration",
- "Homomorphic Encryption",
- "Use cases of cryptography"
+ "DevEx",
+ "Frameworks",
+ "Gaming",
+ "Autonomous World",
+ "onchain",
+ "Autonomous World",
+ "DevEx",
+ "Frameworks"
],
"language": "en",
"speakers": [
- "cperezz"
+ "alvarius"
],
"eventId": "devcon-7",
- "slot_start": 1731391800000,
- "slot_end": 1731392400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/12k_WqxuHHHeL-ozPhNdmibpCzBNzvOlF-4z0chDHOyY"
+ "slot_start": 1731475800000,
+ "slot_end": 1731477600000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/13IffrHXnDmcykkm_fptRD_pUCl4g2eRLtXlWD6o8UUE"
},
"vector": [
0,
0,
0,
+ 6,
0,
0,
0,
@@ -517769,8 +516707,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -517873,6 +516809,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -518234,7 +517171,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -518601,10 +517537,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -518618,10 +517550,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -519071,7 +518006,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -519094,46 +518028,32 @@
},
{
"session": {
- "id": "mpc-tooling-or-how-to-create-mpc-apps",
- "sourceId": "QLMYBD",
- "title": "MPC Tooling or How to create MPC apps",
- "description": "Let's get into the state of the art of MPC development: we'll discuss different MPC schemes, current MPC tooling & how you can create MPC apps today.\r\nWe'll cover the tech stack from a frontend level (e.g. MPC compilers) to a backend - and of course how we can combine them.",
- "track": "Applied Cryptography",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
+ "id": "mud-past-present-and-future",
+ "sourceId": "FE9L3P",
+ "title": "MUD: Past, present, and future",
+ "description": "MUD--an open-source engine for autonomous worlds--was released two years ago in DEVCON Bogotá. Since then, it has gone through many iterations and helped many developers build their onchain games and worlds. Two years later, MUD core developer Alvarius will take stock of where we are and what the future holds for MUD.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "type": "Talk",
+ "expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
+ "keywords": [],
"tags": [
- "Tooling",
- "Cryptography",
- "MPC",
- "Cryptography",
- "MPC",
+ "Autonomous World",
+ "Frameworks",
+ "Gaming",
"Tooling"
],
- "keywords": [
- "Circom-MPC",
- "MPC tooling"
- ],
- "duration": 489,
"language": "en",
- "sources_swarmHash": "8b8ee46fd9725a4ea9ca521e0da429005bef6925bc6bb11dae9ee6fc11c803aa",
- "sources_youtubeId": "eKpcf1JMNak",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f7f280d989c5b7abc08b.vtt",
- "transcript_text": " Hi everyone, my name is Rasul. I work in MPC research team of privacy and scaling explorations. And today I want to talk about MPC tooling or how we can create MPC apps. So what exactly I'm going to go over is like first short introduction, what is MPC? Then I'm going to talk about applications of MPC and then I'm going to talk I'm going to cover tools we work on in our team that allow people to create MPC apps and then short example interesting example of using these tools. So what is MPC? MPC is an interactive protocol that allows parties to jointly compute a function or their inputs while keeping those inputs private. So let's imagine that we have a public function f that takes two parameters, x and y. And let's say party one provides x parameter, party two provides y parameter, and they will be able, parties will be able to compute the output of this function while keeping their individual inputs private. So there are two kinds of MPCs. First one is app-specific and second one is general purpose MPC. So app-specific protocols, MPC protocols are designed to represent one specific function. So let's say threshold signatures, Shamir secret sharing and PSI and many others. And general purpose are designed to represent any function including the all the app specific protocols as well. So there are many applications of MPC. I'm going to mention a few examples. So it's like privacy preserving, preserving machine learning, cost narcs, MPC stats is another great project that PSTM works on, and etc. So first tool I want to talk about is called Circum MPC. Circum MPC is basically a project, a project is a fork of Circum, it's a famous ZK DSL, but it compiles to a universal MPC format called Bristol Fashion Circuit, that can describe Boolean and arithmetic circuit. So why we chose Sercom is because many zk slash cryptography devs already know Sercom and it will be easier for them to create circuits in Sercom. And there's also a big number of circuits written in Sercom already. For example, SercomLibML. And they can be reused without changing the code. And that's actually what we did in PSE as well. We just took circumlibml, Kathy's library, and we were able to run MPC circuits, ML, sorry, in MPC. Another tool I want to talk about is called Summon. Summon is a language for collaboratively summoning computations. And it's another tool that my teammate mostly works on, Andrew Morris, and summon is TypeScript like DSL, similar to Circum NPC, with a goal for user-friendliness. It can be used from or in TypeScript, and therefore it allows to build everything end-to-end in TypeScript. So if you know Cursive Team, they already use a summon tool as well in their apps. And the last tool I want to cover is called CircumMPSpeeds. So first of all, MPSpeeds itself is a big, big framework that people can use to create NPC apps. But it might be a bit hard for beginners to start with it. So what we do, so Circum MPC speeds is basically a transpiler from Bristol format that generated by someone compiler by Circum MPC, and a transpiler from Bristol format to .mpc representation that is required to run the circuit in MPC with MPSpeed's backend. And this project shows an example of running circum-libml machine learning circuits in MPSpeed. And you can find benchmarks and every information about this in the repo. And yeah, as I said, the same tool can be used to transpile circuits generated by someone as well, not only by circum NPC and The last thing I want to talk about is an example of using these tools specifically someone It's a matching game for friends and lovers That Barry Whitehead was talking about last year on Def Connect Istanbul. It's called two PCs for lovers So basically you can play with your friends or with your lover and you can choose love. But if you choose love but the result is friendship, only you will know about your feelings. Even if your friend knows advanced cryptography. And you can try it here. Yep. That's it. Thanks for coming. You can find me by my username, Kairisu. Yep. Thank you, Rizu. Any questions? Oh, there's one. I probably need some help. No. Do you want to try? Yeah, let's go. I'll leave my mic here. There? Sorry. Sorry, Georgi. That was a good direction, so. Okay. I have a question. Did you explore using MPC for building interoperability on bridges? No, actually. No, I don't think so. I don't think so, no. Do you have an idea? Like, for example? Opinion? Yeah, I mean, building interoperability protocols with MPC. No, we weren't doing this. We mostly were focusing with... I work mostly on Circum NPC. So we were focusing on privacy-preserving machine learning. Like, mostly. And, yeah. Not on that case yet. Yeah, sure. I mean, we are just exploring it and getting into it. So I wanted to see more opinions and build our surround that. Okay, thanks. Sorry if I didn't answer it. We see a question over there. Oh, this is a mic. Sorry, I didn't know this was a mic. Siracom usually targets an R1CS backend, and so I'm assuming all of these other tools also. And my question is, do you pay a price for that? Are there other MPC arithmetizations that you work with? Or is there something inherently related to the Seracom toolchain that you find useful here? Sorry, your question is, do we have? So my question is that, sorry. Oh, okay, sorry. I was not here when the DICE was introduced. But my question is that SIRCOM is typically targeting an R1CS backend, and so I'm assuming all these frameworks and toolings are doing the same, but there are some pretty clever other arithmetizations, and I'm wondering if MPC is solely in this domain, or you can make use of other things like Plonk or other repetitions? Yeah, I think it's like, as I mentioned, we like, it's a fork of Sercom, and we don't target R1CS, instead we target Bristol format. Bristol format is a universal MPC format that can describe arithmetic and Boolean circuit, and yeah, it's just like a super simple format, and from this format you universal MPC format that can describe arithmetic and Boolean circuit and Yeah, it's just like a super simple format and from this format You can already I don't know also transpile it to whatever back-end you want So for example MPC library is like another library that PC works on you can target this library You can speak target MP speeds library. Yeah, etc Let's give a big applause to resume",
- "eventId": "devcon-7",
- "slot_start": 1731390600000,
- "slot_end": 1731391200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1F2EhWXcgf32_Gh77ty0p18d2rnEPMZymHL7KX7iwSdE",
- "resources_slides": null,
"speakers": [
- "rasul-ibragimov"
- ]
+ "alvarius"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731553200000,
+ "slot_end": 1731554400000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1OeTy66nVePoVL95ayNDdQbYFQRdNCNjTM0xMIccPtWE"
},
"vector": [
0,
@@ -519146,11 +518066,9 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -519251,6 +518169,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -519612,7 +518531,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -519901,7 +518819,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -519977,46 +518894,38 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -520449,10 +519358,18 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
2,
0,
0,
@@ -520471,54 +519388,34 @@
},
{
"session": {
- "id": "mpcstats",
- "sourceId": "ND3S9R",
- "title": "MPCStats",
- "description": "MPCStats is a framework allowing data consumers to query statistical computation from either one or multiple data providers while preserving privacy to those raw data. We support standard statistical operations, including nested and filter ones. Data providers do not leak their data and data consumers can be convinced the computation is done correctly.",
+ "id": "multi-party-fhe-for-multi-player-privacy",
+ "sourceId": "S9S8M9",
+ "title": "Multi-Party FHE for Multi-Player Privacy",
+ "description": "Privacy is an unsolved challenge for blockchains and decentralized systems. ZK cryptography gets us there partially, but not all the way. ZK enables “single-player private state,” and certain other kinds of privacy are impossible to realize with ZKPs alone. Panelists, the cryptography library devs, infrastructure builders, and application devs who have recently started to explore programmable encryption will discuss MP-FHE as one such tool for achieving more general privacy capabilities.",
"track": "Applied Cryptography",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
+ "type": "Panel",
+ "expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Tooling",
- "Privacy",
- "MPC",
- "Public good",
- "verification",
- "computation",
- "MPC",
- "Privacy",
- "Public good",
- "Tooling"
- ],
"keywords": [
- "privacy-preserving",
- "data analysis",
- "MPC",
- "statistics",
- "verifiable computation"
+ "mp",
+ "fhe",
+ "programmable cryptography"
],
- "duration": 508,
+ "tags": [],
"language": "en",
- "sources_swarmHash": "9b8211a5308190cf41598cd33cefed8af79e239f4d4c5a6648a32a2cbcf77f51",
- "sources_youtubeId": "wCp7Zsjou7w",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6733041280d989c5b7bfec34.vtt",
- "transcript_text": " Hello everyone. So we're MPC's stats team at BSC. So today we'll introduce our project, and it's currently worked on by Jern and I and Kazumune. So the goal of our project is to build a framework that allows users to query statistical computation across different data providers. We'll guarantee the data privacy and also the correctness of the result. We've implemented common statistical operations using MP-SPEEDS, which is a well-known MPC framework. We've supported 12 statistical operations, and also some common table join and array concatenation and filtering. So users can define computation like this. And we also integrated TLS notary so that the inputs to MPC are authenticated from some well-known websites so that we can prevent garbage in, garbage out situation. All right, thank you, Kevin. So basically, right now, we are talking about MPC, right? So intuitive approach for MPC is that having all parties, data providers, data consumers, to join as a competition parties, right? The bad things, I mean, the good thing for us, let's say, is that it's free verifiability because everyone is in the same, like, competition set, right? So they know, like, what competition is done, right? I request mean, I know that this guy just compute mean for me, right? The bad thing is that the data providers, consumers, everyone need to be online at the same time. And it's really hard, right, for many numbers of data providers, especially when the number of data providers grows, the computations grow skyrocket so badly. So how to solve that, right? We use another approach called client interface, which basically means that the data providers and data consumers are not in the computation parties. So there's three phases. The first phase is that data providers secretly share the data through some delivery links. They can log in, share data, and log out. And then another set of computation parties compute data, and once it's ready, data consumers just log in to get it out. So this is good because now the data provider and consumer doesn't need to be online at the same time, which makes sense. And it also doesn't grow with the number of data provider because the cost of the MPC computation is actually from the number of the parties in the computation parties. The bad thing is that the data providers and consumer now need to trust the parties, right? It depends on our setup. If it's malicious, we need to trust at least one of the parties is right. And again, because we are not joining in the NPC computation party itself, we have no idea what is the function that they calculate is actually the one we want. But again, the trust assumption is the same. If you trust that at least one of the malicious setting of the computation party is honest, we can be sure that they just run the computation that we want, like mean or median or anything we want. So use case, we are thinking about cross-department data sharing government, verifiable salary data, any survey research for policy planning. And yeah, many more, let us know. So demo time. So this is really up and running. We're still under maintenance, final optimization, because it's pretty big. So we will notify soon. But it's pretty interesting to explore ETH balance inequality at DEF CON. So what it means, you guys can use your Binance to share it privately. We won't know your Binance balance, but then we will be able to calculate the interesting stats we will show later. But you guys should join this group first. So we will notify by today, tomorrow, once the Docker file is smaller so that it can make sense to run in this internet, in DevCon. So the caveat, right, because we want to be upfront, so we will only allow you to share privately the free in-your-spot balance of Binance. And again, the parties could still learn the number of digits, although this comes from the limitation over here. It's not itself that the parties still know the number of digits of your finance balance but again we won't know actually the number and again this is the trust assumption that we trust that our three party doesn't collude right and please please join this telegram group we will get a bit soon and anyone who join will get a chance to win an NFT and win a lottery as an actual cash so yeah so this is just a quick go through it will already be in our readme, in our demo. So, get Binance API key, just go, yeah, Binance API key. Everyone knows how to do that. Get the API key and secret key. Make sure it's read only. And then, yes, so notarize this. This is only our script that you need to run. You just get clone and each address is just address for receiving the price. This is not the address for the Binance. This is just to send the price if you want one. And yeah, this is the website. So we are having max ETH balance of DEFCON, mean, median, number and Gini coefficient to make sure of the inequality. So yeah, join us. Thank you so much. Thank you, Kevin, John. Any questions? Oh, that's too far. Okay, you got it. Hey, great talk. It's not clear to me. Are you guys trying to collect aggregate statistics from multiple parties? And if that's the case and that's the use case, it's not clear to me, are you guys trying to collect aggregate statistics from multiple parties, and if that's the case and that's the use case, did you explore something like a Brio-like system, using function secret sharing? I don't think MP Speed supports that, so I'm kind of curious. It should be much, much more efficient. Yeah, thank you so much for the suggestion. Yeah, I think we've looked through some of it, but this limitation mostly is through the number of data providers. So, right now, again, like FHG, multi-key, functional encryption, secret string, yeah, we looked through some of them, and we're thinking of using some, but again, the limitation right now is that the state-of-the-art MPC of a huge number of provider, it still matters. And we think again, because we make sure that we don't want the competition to just grow indefinitely with the number of data providers, so we still use this. But thank you so much. Yeah, so just look at function secret sharing. I think it would really, really boost your results. Thank you. I appreciate function secret sharing. Note. Do we have any other questions? Oh, there's one. Hi, I was trying to scan the TG QR code that you showed just now, and it says link expired for me. Is it just t.me slash NPC stats as a link? Yes, yes. Okay. Sorry about this. So t.me slash NPC stats. Any other question? Can I ask a question? I know that the federated learning is similar to preserving privacy and then the medical hospitals, they're having a lot of confidential data of the patients, so they use federated learning. I just wonder what you're presenting, how different it is from federated learning. Yeah, so basically federated learning is like you train offline, right? Like data is still there, and then you send the update on the gradient descent or anything to your machine learning app in the air, right? So basically you train everything up there. But now, MPC, it means that you gather data from different parties and compute at the same time. So for federated learning, it can just actually, it depends on what types of things you use, but it can also use MPC itself So but yeah when it comes to fit running people still consider like not too many parties or at once But when we are thinking about stats, we are thinking about like population So we wish to make it more scalable into a number of data providers itself But yes, I think a lot of federated learning techniques to use MPC But we just want to make sure that MPC framework that really scalable to a huge number of data providers. Yes. Okay. Thank you",
- "eventId": "devcon-7",
- "slot_start": 1731396000000,
- "slot_end": 1731396600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/10sZNPm9ETDOiRts7vDo9aVWovdRE2PpqvKAxR6_9Lv8",
- "resources_slides": null,
"speakers": [
- "kevin-chia",
- "teeramet-jern-kunpittaya"
- ]
+ "gubsheep",
+ "veronica-zheng",
+ "eduard-sanou",
+ "janmajaya-mall"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731564000000,
+ "slot_end": 1731567600000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1i64ImNoehhB-Dnpix_z7zP--wGTsTmeikoll2OE-lGI"
},
"vector": [
0,
@@ -520648,6 +519545,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -520702,6 +519600,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -520937,6 +519836,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -520993,13 +519893,12 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -521294,7 +520193,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -521362,7 +520260,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -521382,14 +520279,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -521620,7 +520515,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -521694,7 +520588,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -521834,12 +520727,13 @@
0,
0,
0,
- 2,
0,
0,
0,
2,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -521856,45 +520750,38 @@
},
{
"session": {
- "id": "mud-how-we-built-an-evm-application-framework-from-the-ground-up",
- "sourceId": "883QBY",
- "title": "MUD - How we built an EVM application framework from the ground up",
- "description": "We wanted to accomplish one simple task: put a game—with all its data and logic—on a blockchain. What followed were countless technical challenges, years of efforts, and learnings that are applicable to anyone building complex onchain apps.\r\n\r\nHow should data be structured? How can complex world state stay up-to-date on the client? How do we allow multiple teams to build on one single world, without it all breaking apart? Join us as we share the pitfalls and learnings.",
- "track": "Developer Experience",
- "type": "Talk",
+ "id": "multi-party-fully-homomorphic-encryption-mp-fhe-in-practice",
+ "sourceId": "QC7FH7",
+ "title": "Multi-Party Fully Homomorphic Encryption (MP-FHE) in Practice",
+ "description": "In this session, we will break down the FHE game Frogzone, which required advancements at every layer of the cryptographic software stack: cryptography libraries and tooling, circuits, software infrastructure, and even DevOps. We will also cover additional use cases for FHE at a technical level.",
+ "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Onchain",
- "Games"
+ "Programmable",
+ "Cryptography"
],
"tags": [
- "DevEx",
- "Frameworks",
- "Gaming",
- "Autonomous World",
- "onchain",
- "Autonomous World",
- "DevEx",
- "Frameworks"
+ "Cryptography",
+ "Homomorphic Encryption"
],
"language": "en",
"speakers": [
- "alvarius"
+ "gubsheep",
+ "riley-wong-theythem",
+ "eduard-sanou",
+ "han-jian"
],
"eventId": "devcon-7",
- "slot_start": 1731475800000,
- "slot_end": 1731477600000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/13IffrHXnDmcykkm_fptRD_pUCl4g2eRLtXlWD6o8UUE"
+ "slot_start": 1731648600000,
+ "slot_end": 1731654000000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/15m-ipmgu4kmVNAWtsY-5mdugROSn_lIoAK6AY-lB8wM"
},
"vector": [
- 0,
- 0,
- 0,
- 6,
0,
0,
0,
@@ -521909,6 +520796,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -522005,7 +520893,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -522077,6 +520964,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -522369,6 +521257,9 @@
0,
0,
0,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -522653,6 +521544,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -522673,7 +521565,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -522730,6 +521621,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -522748,13 +521640,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -523065,7 +521954,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -523208,7 +522096,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -523219,6 +522106,7 @@
0,
0,
0,
+ 2,
0,
0,
0
@@ -523226,32 +522114,38 @@
},
{
"session": {
- "id": "mud-past-present-and-future",
- "sourceId": "FE9L3P",
- "title": "MUD: Past, present, and future",
- "description": "MUD--an open-source engine for autonomous worlds--was released two years ago in DEVCON Bogotá. Since then, it has gone through many iterations and helped many developers build their onchain games and worlds. Two years later, MUD core developer Alvarius will take stock of where we are and what the future holds for MUD.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "id": "multiparty-homomorphic-encryption-from-ring-learning-with-errors",
+ "sourceId": "KS7H3H",
+ "title": "Multiparty Homomorphic Encryption from Ring-Learning-with-Errors",
+ "description": "This talk will introduce Ring Learning with Errors (RLWE) based Multiparty Homomorphic Encryption (MHE).",
+ "track": "Applied Cryptography",
"type": "Talk",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [],
"tags": [
- "Autonomous World",
- "Frameworks",
- "Gaming",
- "Tooling"
+ "Open Source Software",
+ "Homomorphic Encryption",
+ "Use cases of cryptography",
+ "Security",
+ "Use Cases",
+ "Homomorphic Encryption",
+ "Open Source Software",
+ "Security",
+ "Use Cases",
+ "Use cases of cryptography"
],
"language": "en",
"speakers": [
- "alvarius"
+ "jean-philippe-bossuat"
],
"eventId": "devcon-7",
- "slot_start": 1731553200000,
- "slot_end": 1731554400000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1OeTy66nVePoVL95ayNDdQbYFQRdNCNjTM0xMIccPtWE"
+ "slot_start": 1731569400000,
+ "slot_end": 1731571200000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1qdDRslHeX1rQN30xep6TupLd5KYw4-agBG6u4Zh17dA"
},
"vector": [
0,
@@ -523264,9 +522158,12 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
0,
0,
- 6,
0,
0,
0,
@@ -523368,7 +522265,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -523730,6 +522626,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -524000,6 +522897,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -524078,6 +522976,40 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -524111,46 +523043,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -524566,10 +523458,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
2,
0,
@@ -524583,40 +523475,39 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "multi-party-fhe-for-multi-player-privacy",
- "sourceId": "S9S8M9",
- "title": "Multi-Party FHE for Multi-Player Privacy",
- "description": "Privacy is an unsolved challenge for blockchains and decentralized systems. ZK cryptography gets us there partially, but not all the way. ZK enables “single-player private state,” and certain other kinds of privacy are impossible to realize with ZKPs alone. Panelists, the cryptography library devs, infrastructure builders, and application devs who have recently started to explore programmable encryption will discuss MP-FHE as one such tool for achieving more general privacy capabilities.",
- "track": "Applied Cryptography",
- "type": "Panel",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "id": "my-mother-will-not-use-it",
+ "sourceId": "HKKFQX",
+ "title": "\"My mother will not use it\"",
+ "description": "In this Talk, I want to cover the different mindsets designers need to improve and optimize the work for web3.\r\nIf we're going to change the way we interact with each other and aim to profoundly improve society with this technology, we can't think and use the same methodologies.\r\nWe will cover topics such as the target audience (the title of the Talk), testing, the learning curve, web2 to web3, and more.",
+ "track": "Usability",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Design",
"featured": false,
"doNotRecord": false,
"keywords": [
- "mp",
- "fhe",
- "programmable cryptography"
+ "Inspiration"
+ ],
+ "tags": [
+ "inspiration",
+ "Design",
+ "Design Thinking",
+ "UI/UX"
],
- "tags": [],
"language": "en",
"speakers": [
- "gubsheep",
- "veronica-zheng",
- "eduard-sanou",
- "janmajaya-mall"
+ "nuno-loureiro"
],
"eventId": "devcon-7",
- "slot_start": 1731564000000,
- "slot_end": 1731567600000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1i64ImNoehhB-Dnpix_z7zP--wGTsTmeikoll2OE-lGI"
+ "slot_start": 1731559800000,
+ "slot_end": 1731560400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1phw7po5lIFL6aJaipzIR4HdBRmhdugA212mJKjaQfoc"
},
"vector": [
0,
@@ -524627,8 +523518,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -524747,8 +523636,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -524802,8 +523689,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -525038,7 +523923,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -525098,7 +523982,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -525106,6 +523989,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -525434,6 +524318,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -525517,6 +524402,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -525794,6 +524681,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -525932,11 +524820,10 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
@@ -525948,42 +524835,62 @@
0,
0,
0,
+ 2,
0,
0
]
},
{
"session": {
- "id": "multi-party-fully-homomorphic-encryption-mp-fhe-in-practice",
- "sourceId": "QC7FH7",
- "title": "Multi-Party Fully Homomorphic Encryption (MP-FHE) in Practice",
- "description": "In this session, we will break down the FHE game Frogzone, which required advancements at every layer of the cryptographic software stack: cryptography libraries and tooling, circuits, software infrastructure, and even DevOps. We will also cover additional use cases for FHE at a technical level.",
- "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC",
- "type": "Workshop",
- "expertise": "Intermediate",
- "audience": "",
+ "id": "mycofi-mycelial-design-patterns-for-web3-and-beyond",
+ "sourceId": "8CDPFC",
+ "title": "MycoFi: Mycelial Design Patterns for Web3 & Beyond",
+ "description": "Exploring MycoFi guides readers on an underground exploration into the world wise web of mycelial networks, the most prolific producers of public goods on Earth. This talk examines how the evolutionary adaptability of fungi could help us imagine biomimetic alternatives to status-quo economic systems that demand infinite growth on a finite planet. If we aim to design regenerative economies, what better\r\nplace to start than with the thriving evolutionary patterns of nature?",
+ "track": "Coordination",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Programmable",
- "Cryptography"
- ],
"tags": [
- "Cryptography",
- "Homomorphic Encryption"
+ "Collective Intelligence",
+ "Conviction",
+ "Consensus Mechanisms",
+ "Civil Resistance",
+ "Sustainability",
+ "Public good",
+ "Regenerative Applications",
+ "Design Thinking",
+ "Civil Resistance",
+ "Collective Intelligence",
+ "Consensus Mechanisms",
+ "Conviction",
+ "Design Thinking",
+ "Public good",
+ "Regenerative Applications",
+ "Sustainability"
],
- "language": "en",
- "speakers": [
- "gubsheep",
- "riley-wong-theythem",
- "eduard-sanou",
- "han-jian"
+ "keywords": [
+ "nope"
],
+ "duration": 544,
+ "language": "en",
+ "sources_swarmHash": "f520b12bc12e6e339bfff3be9b1d59b5019047a45c6c94f2fc1557b7e458af07",
+ "sources_youtubeId": "0A4jXL5eBaI",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731648600000,
- "slot_end": 1731654000000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/15m-ipmgu4kmVNAWtsY-5mdugROSn_lIoAK6AY-lB8wM"
+ "slot_start": 1731410400000,
+ "slot_end": 1731411000000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1vPpKjEWNW5rkIevCpxSX6qLuE5usbq91oz2FVQk6gWw",
+ "resources_slides": null,
+ "speakers": [
+ "jeff-emmett"
+ ]
},
"vector": [
0,
@@ -525997,9 +524904,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -526169,8 +525073,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -526465,15 +525367,13 @@
0,
0,
0,
- 6,
- 6,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -526751,7 +525651,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -526777,6 +525676,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -526828,7 +525728,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -526852,6 +525751,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -526873,6 +525773,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -526885,6 +525786,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -526934,6 +525836,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -526968,6 +525871,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -527087,6 +525991,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -527160,6 +526065,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -527302,6 +526208,7 @@
2,
0,
0,
+ 2,
0,
0,
0,
@@ -527313,54 +526220,46 @@
0,
0,
0,
- 2,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "multiparty-homomorphic-encryption-from-ring-learning-with-errors",
- "sourceId": "KS7H3H",
- "title": "Multiparty Homomorphic Encryption from Ring-Learning-with-Errors",
- "description": "This talk will introduce Ring Learning with Errors (RLWE) based Multiparty Homomorphic Encryption (MHE).",
- "track": "Applied Cryptography",
+ "id": "native-account-abstraction-in-pectra-rollups-and-beyond-combining-eof-eip-7702-and-rip-7560",
+ "sourceId": "7AWG3A",
+ "title": "Native Account Abstraction in Pectra, rollups and beyond: combining EOF, EIP-7702 and RIP-7560",
+ "description": "Account Abstraction has rightfully become one of the most discussed topics in the Ethereum ecosystem.\r\nThe upcoming Pectra upgrade is set to be the first one to improve EOAs by including EIP-7702.\r\nBut can EIP-7702 alone achieve \"Account Abstraction\"?\r\n\r\nWe will discuss the challenges and benefits of EIP-7702, and break down the team's vision for achieving \"complete\" Native Account Abstraction with RIP-7560/EIP-7701 and how it differs from ERC-4337 + EIP-7702.",
+ "track": "Core Protocol",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
- "featured": false,
+ "expertise": "Expert",
+ "audience": "Engineering",
+ "featured": true,
"doNotRecord": false,
- "keywords": [],
+ "keywords": [
+ "Native Account Abstraction",
+ "RIP-7560",
+ "EIP-7702"
+ ],
"tags": [
- "Open Source Software",
- "Homomorphic Encryption",
- "Use cases of cryptography",
- "Security",
- "Use Cases",
- "Homomorphic Encryption",
- "Open Source Software",
- "Security",
- "Use Cases",
- "Use cases of cryptography"
+ "In-protocol Account Abstraction",
+ "Rollups",
+ "Account Abstraction",
+ "eip-7702",
+ "Account Abstraction",
+ "In-protocol Account Abstraction",
+ "Rollups"
],
"language": "en",
"speakers": [
- "jean-philippe-bossuat"
+ "alex-forshtat"
],
"eventId": "devcon-7",
- "slot_start": 1731569400000,
- "slot_end": 1731571200000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1qdDRslHeX1rQN30xep6TupLd5KYw4-agBG6u4Zh17dA"
+ "slot_start": 1731562200000,
+ "slot_end": 1731564000000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1sZ2P4U7wWwVav4ska4SCGMtylu-lx2sWw0ymD92gTtY"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -527837,14 +526736,12 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -528107,7 +527004,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -528135,7 +527031,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -528156,6 +527051,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -528164,6 +527060,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -528186,7 +527083,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -528197,7 +527093,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -528205,7 +527100,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -528334,6 +527228,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -528465,6 +527360,12 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -528668,12 +527569,13 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
2,
+ 2,
+ 0,
0,
0,
0,
@@ -528690,34 +527592,45 @@
},
{
"session": {
- "id": "my-mother-will-not-use-it",
- "sourceId": "HKKFQX",
- "title": "\"My mother will not use it\"",
- "description": "In this Talk, I want to cover the different mindsets designers need to improve and optimize the work for web3.\r\nIf we're going to change the way we interact with each other and aim to profoundly improve society with this technology, we can't think and use the same methodologies.\r\nWe will cover topics such as the target audience (the title of the Talk), testing, the learning curve, web2 to web3, and more.",
- "track": "Usability",
+ "id": "native-implementation-of-ephemery-testnet-on-besu-and-teku-client-pairs",
+ "sourceId": "EAABPS",
+ "title": "Native Implementation of Ephemery Testnet on Besu & Teku Client Pairs",
+ "description": "This presentation covers the work done to enable native support for Ephemery on Teku and Besu clients. Ephemery is a short-lived, resettable testnet designed to automatically revert to its genesis state after a defined period, making it ideal for intensive, short-term testing without concerns over issues like insufficient testnet funds, inactive validators, or state bloat that long-running testnets often face.",
+ "track": "[CLS] EPF Day",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Design",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Inspiration"
- ],
"tags": [
- "inspiration",
- "Design",
- "Design Thinking",
- "UI/UX"
+ "Consensus",
+ "Developer Infrastructure",
+ "User Experience"
],
- "language": "en",
- "speakers": [
- "nuno-loureiro"
+ "keywords": [
+ "Client Development",
+ "Teku",
+ "Besu",
+ "Ephemery"
],
+ "duration": 847,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "eciNYIzb7gE",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67347bee9dbb7a90e163940f.vtt",
+ "transcript_text": " Hello everyone. How are you guys doing today? I hope you're having a great time at DEF CON. Okay, so today I'm going to be talking about native implementation of ephemerate testnet on client pairs, Terco and Bessu. First of all, I'm Glory, and I would like to ask this question. How many of us have heard of the word Ephemery Testnet before now? Okay, so those people that raised their hand are people in the fellowship. So that means we still have so many persons that are here to know about Ephemery. I remember when I started working on this project, my mentors, the guys from Techco and Best Studio, were like, what is ephemeris? I've not heard of it before. So I had to start explaining. I had to share the link to the documentation for them to go through it. OK, so with that being said, um. OK. That being said... All right, so why they're trying to work on it. First of all, what is ephemery? Ephemery is a resettable short-term-based testnet. So when we say it's resettable, it gets to reset itself after a given period of time. So it's not like the regular testnets that we are used like Sepolia or LISC-E and the rest of them. So eFirmary is kind of dynamic and not like the others like I said. So I wouldn't really want to go deep into eFirmary, so I'll just be diving into what I actually worked on. So yeah, for the project, the goal of the project was for me to implement or create native support for ephemery on Besso and Circle clients. And why was this needed? We realized that just like I asked, most of you didn't know about ephemery. So ephemery is still pretty new, and we are trying to see how we can get more clients and more people to know about it and to start using it. So we want to improve the user adoption and we want more clients to be running on eFirmware natively without having to go into the manual process of setting it up. So based on the work that I've done, initially when I started this project I noticed there are some work that I've done before in the past by some other fellows and at that time we had support for Forget, Red and Lighthouse and Luster so work has started for these clients. I don't think they are completed yet but as at the time I came in I noticed there was no native support for Teco. So for that, we needed to download the Genesys SSD files and the Genesys files and all of that to do those processes manually when trying to run the node. So to avoid that headache, we decided to implement native support for it. And what does that really mean when we talk about native support? We want a situation whereby when you are trying to run a node, you can easily do something like besu-network-efermary, just like you do with other supported clients like Sepulia and the rest. So because efermary is quite different, the process of implementing it on clients was not as straightforward like with other clients. So we needed to do things like trying to write some custom functions or some custom classes as well to be able to work on the updating of the genesis state and all that. So because we understand that ephemeris updates after a certain period of time, so there was need for a custom function to be created for that to be able to happen dynamically. So these were some of the things I did. Okay, so for the ephemeris genesis 5, I noticed the way it is structured when I checked the original repository, it was quite different from what Best to Clients was expecting. So I had to make some changes like other things like the S-Arch, the discovery nodes and the boot nodes to the Genesis file itself. And also I updated the documentation when I was done with the work so that when you go to their documentation now, you can see, just like you see Sepulia Oliske on their doc, you can see a family there and know the right command for you to run to be able to do that. And with this, we also implemented some testing because every aspect of this project, with the way BestESU client works, everything you do you have to write tests for it. So every implementation work done here was also properly tested. And so for TEKU we did similar stuff but with TEKU, you know, for the CL clients we don't use the normal JSON format file for the genesis so it was SSE and it and it's not as easy to manipulate as you do with the genesis format file. So with that, we needed to take a different approach and see how we can load the ssd file from the ephemera repository to get the updated states at every given point in time. So the same thing applies with Tecku. We also created a custom class and function to be able to update the Genesys states at every given point in time dynamically. So if you're running the node, you're able to get the updated states every time, so you don't need to go to the ephemeral website to go download it and use on your system. And also with Tecku, I worked on the reset feature, which means if you are running a node, you don't have to stop the node manually. So go delete your database and all of those stuff. When it's due for resets, it resets itself and then deletes all the necessities that needs to be deleted in the DB. Yeah, so pretty much like I said earlier, there's not much difference between the implementation on Serco and Bessu, just some different files and changes that were made, which was not exactly the same thing. And then the SSE file I mentioned and Genesis file and all of that. OK, so yeah, so this is like a summary of everything I did on the implementation for Terco and BESU. I completed the initial research, then created a custom function for ephemera on both BESU and the Terco clients, and then right now you can have native support on both then right now you can have, right now we have native support on both clients, so you can use the flag, the native flag like BESU.network.fmri or Terco.network.fmri and you can do that as well. And then the documentations are also properly updated and we have suitable tests for all of this. So in summary, for the whole period of the fellowship, I was able to get up to 15 PROs merged and currently have one PRO that I'm still working on and one open issue. So as far as work in progress goes, based on what I planned to do during the course of the fellowship, I wasn't able to get to the point where I was able to work on the reset feature. So right now I still have the reset feature to implement on BESU, and then as far as the website goes, I'm still yet to work on that, just redesigning the website and the tutorial work through, which I plan to do, but I didn't have enough time to do that before now. For the challenges, these are some of the challenges I faced. This was my first time working on protocol development. Before now, I do normal application level development. I write in smart contracts, doing dabs and all that. So this was my first time. And it was a lot of learning process. Had to learn about the protocol, CL, EL. And that was one thing I love about this project, because it gave me the opportunity to learn about those different areas. And then trying to understand the code base for each of these clients was another big problem. It wasn't even writing the code itself, but going through their code base, trying to figure out where my implementation is going to be, those were some of the challenges I had. But thankfully enough, I had good mentors who were able to help me navigate that. So for the future of the project, I plan to continue my work on the BESU client to complete the research future and to also implement there's still some little work I need to do on TEKU for the validator clients on slots processing and then to expand the support to other clients. So right now, we have some clients that don't currently have native supports. So my plan is to continue working and to extend support to those other clients, and also to become a validator, an ephemera validator. So key takeaways for me, this program has given me the opportunity to dive into the Ethereum protocol itself, which was one of the reasons I joined. And then I've had the opportunity to learn a lot about what the protocol entails, client implementation, what the different clients we have in the Ethereum protocol and all of that. And then before now, I do Java. Java was actually like my very first programming language when I started. But I've not done it for like more than four years or so. But with this project, I've come back to Java. And I was able to like improve on my skills as far as Java goes, as well as testing and all that. Then for EIP, I've not actually implemented anything working with an EIP before, but this project actually gave me the opportunity to write code following an EIP, so that was really good for me. Yeah, so for my mentor, special thanks to Paul Harris from the TECO team. Unfortunately, they are not here right now. And then, thanks to Sally from the BESO team. Thanks to Mario and PK910 from the eFMRI team and the past fellow, Oli. When I started I asked her some few questions and she also shared some of her past updates with me which was really helpful as well. And thanks to Josh and Mario once again for the opportunity and for setting this fellowship up. So before I go, I'd like to encourage anyone here that wants to, that is considering contributing to ephemeric. So if you want to do that, you can do that in different ways by you can be a node runner, you can implement on client, like I mentioned can be a node runner, you can implement on client, like I mentioned earlier, we still have some client that need implementation, and then you can, if you're a dApp developer, you can deploy to, you can deploy to a family test net on your dApp and run a test and see how it goes, and if you run node, you can also run, sorry, if you run infrastructure, you can run an infrastructure, and if you have any idea or whatever, you can communicate with us to learn more. Okay, so about this, so there's currently an incentivization program on eFemery that gives you an opportunity to contribute and also get incentivized for it. So, okay, let me not be fast to remove it. So in case you want to scan it, you can quickly scan it before I remove the slide. All right. So, yeah, so this is like summary of the work that has been done and what is yet to be done in terms of client implementation. So that's for EL clients, and then this is also for the CL clients. And for resources, if you want to learn more about Ephemery, you can check Ephemery.dev. And to join the community, you can check the Ephemery Metrics community. Thank you very much. All right. Thank you, Glory. Any questions for Glory about her work on the Ephemery testnet implementations? I wonder, is it something different to become a ephemer-e validator? No, no, it's not. The same way you are validator for that network, you can do the same for ephemer validator? No, no, it's not. The same way you are validator for that network, you can do the same for ephemer. So you still need 32Es? So I didn't get asked. You still need 32Es? Ephemer, yes. Oh, okay. Anyone else? Yeah, not really a question, just a comment. Like, a huge thank you. I mean, many, many thanks for all your work on ephemera. Like, it's an incredible job what you've done, implementing it and fully merging it and have it usable in both clients. It's incredible. Thank you so much for mentioning all the resources, the incentivization program. And, yeah, like, anybody can run a validator because being reset every month, resources, the incentivization program. And yeah, like anybody can run a validator because being reset every month, FMRI has infinite ETH for you, so you can just run as many validators as possible, maybe even more than mainnet at one point. But yeah, thank you so much, Glory. FMRI was created basically at DEF CON two years ago, and now after two years, it's amazing to see such an amazing job being done on the network. So yeah,",
"eventId": "devcon-7",
- "slot_start": 1731559800000,
- "slot_end": 1731560400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1phw7po5lIFL6aJaipzIR4HdBRmhdugA212mJKjaQfoc"
+ "slot_start": 1731484800000,
+ "slot_end": 1731485700000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/18GeJQc_Z-ecQcsBsDbtRfawOuvBvptEDPby_7BDdqUU",
+ "resources_slides": null,
+ "speakers": [
+ "glory-justin"
+ ]
},
"vector": [
0,
@@ -528728,8 +527641,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -528737,6 +527648,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -529475,6 +528387,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -529485,6 +528398,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -529522,6 +528436,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -529531,8 +528446,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -529615,8 +528528,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -529895,7 +528806,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -530037,6 +528947,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -530048,62 +528959,45 @@
0,
0,
0,
- 2,
0,
0
]
},
{
"session": {
- "id": "mycofi-mycelial-design-patterns-for-web3-and-beyond",
- "sourceId": "8CDPFC",
- "title": "MycoFi: Mycelial Design Patterns for Web3 & Beyond",
- "description": "Exploring MycoFi guides readers on an underground exploration into the world wise web of mycelial networks, the most prolific producers of public goods on Earth. This talk examines how the evolutionary adaptability of fungi could help us imagine biomimetic alternatives to status-quo economic systems that demand infinite growth on a finite planet. If we aim to design regenerative economies, what better\r\nplace to start than with the thriving evolutionary patterns of nature?",
+ "id": "navigating-developer-liability-in-open-source-code",
+ "sourceId": "EXNLU9",
+ "title": "Navigating Developer Liability in Open-Source Code",
+ "description": "In software development, open-source code has become a cornerstone of innovation and collaboration. However, with this comes the issue of developer liability. As seen by the Tornado Cash case, developers and users can be held liable for how open-source code is used, showing the need for developers to be aware of, and navigate, the legal landscape to mitigate potential risks. This session will demystify the legal implications for developers contributing to and using open-source code projects.",
"track": "Coordination",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Research",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Collective Intelligence",
- "Conviction",
- "Consensus Mechanisms",
- "Civil Resistance",
- "Sustainability",
- "Public good",
- "Regenerative Applications",
- "Design Thinking",
- "Civil Resistance",
- "Collective Intelligence",
- "Consensus Mechanisms",
- "Conviction",
- "Design Thinking",
- "Public good",
- "Regenerative Applications",
- "Sustainability"
- ],
"keywords": [
- "nope"
+ "developer",
+ "liability"
+ ],
+ "tags": [
+ "DevEx",
+ "Open Source Software",
+ "Regulation",
+ "developer",
+ "liability",
+ "DevEx",
+ "Open Source Software",
+ "Regulation"
],
- "duration": 544,
"language": "en",
- "sources_swarmHash": "f520b12bc12e6e339bfff3be9b1d59b5019047a45c6c94f2fc1557b7e458af07",
- "sources_youtubeId": "0A4jXL5eBaI",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731410400000,
- "slot_end": 1731411000000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1vPpKjEWNW5rkIevCpxSX6qLuE5usbq91oz2FVQk6gWw",
- "resources_slides": null,
"speakers": [
- "jeff-emmett"
- ]
+ "eva-wong"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731651000000,
+ "slot_end": 1731652800000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1FCTkULbE1nJ5N4av3cRDnv1nW2exLL3rZv06S06zjGU"
},
"vector": [
0,
@@ -530589,7 +529483,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -530886,13 +529779,14 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -530953,6 +529847,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -530961,13 +529856,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -530989,7 +529884,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -531002,7 +529896,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -531031,6 +529924,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -531052,7 +529946,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -531088,7 +529981,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -531208,7 +530100,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -531419,13 +530310,13 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -531441,43 +530332,41 @@
},
{
"session": {
- "id": "native-account-abstraction-in-pectra-rollups-and-beyond-combining-eof-eip-7702-and-rip-7560",
- "sourceId": "7AWG3A",
- "title": "Native Account Abstraction in Pectra, rollups and beyond: combining EOF, EIP-7702 and RIP-7560",
- "description": "Account Abstraction has rightfully become one of the most discussed topics in the Ethereum ecosystem.\r\nThe upcoming Pectra upgrade is set to be the first one to improve EOAs by including EIP-7702.\r\nBut can EIP-7702 alone achieve \"Account Abstraction\"?\r\n\r\nWe will discuss the challenges and benefits of EIP-7702, and break down the team's vision for achieving \"complete\" Native Account Abstraction with RIP-7560/EIP-7701 and how it differs from ERC-4337 + EIP-7702.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Expert",
+ "id": "navigating-stablecoin-yields-and-risks",
+ "sourceId": "YT9SMK",
+ "title": "Navigating Stablecoin Yields and Risks",
+ "description": "This panel brings DeFi experts together to discuss stablecoin risks, including economic risks related to stabilisation methods, technical risks of smart contracts, and regulatory challenges. We will discuss solutions that can help mitigate risks in this rapidly evolving space and the challenges of promoting risk-driven decisions over trend-driven ones.",
+ "track": "Cryptoeconomics",
+ "type": "Panel",
+ "expertise": "Intermediate",
"audience": "Engineering",
- "featured": true,
+ "featured": false,
"doNotRecord": false,
"keywords": [
- "Native Account Abstraction",
- "RIP-7560",
- "EIP-7702"
+ "Stablecoin",
+ "DeFi"
],
"tags": [
- "In-protocol Account Abstraction",
- "Rollups",
- "Account Abstraction",
- "eip-7702",
- "Account Abstraction",
- "In-protocol Account Abstraction",
- "Rollups"
+ "Frameworks",
+ "Best Practices",
+ "defi",
+ "Best Practices",
+ "Frameworks"
],
"language": "en",
"speakers": [
- "alex-forshtat"
+ "ariah-klages-mundt",
+ "tammy-yang",
+ "alessandro-buser",
+ "colin-platt"
],
"eventId": "devcon-7",
- "slot_start": 1731562200000,
- "slot_end": 1731564000000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1sZ2P4U7wWwVav4ska4SCGMtylu-lx2sWw0ymD92gTtY"
+ "slot_start": 1731488400000,
+ "slot_end": 1731492000000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/15OlMPy7qIjacZlozudJLl0FrCp0kPt_kx5nIRNHipwE"
},
"vector": [
- 0,
- 0,
0,
0,
6,
@@ -531961,6 +530850,10 @@
0,
0,
0,
+ 0,
+ 6,
+ 6,
+ 6,
6,
0,
0,
@@ -532254,6 +531147,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -532270,7 +531164,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -532279,7 +531172,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -532329,6 +531221,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -532413,6 +531307,47 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -532447,7 +531382,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -532580,52 +531514,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -532789,11 +531677,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
2,
- 2,
0,
0,
0,
@@ -532811,48 +531699,33 @@
},
{
"session": {
- "id": "native-implementation-of-ephemery-testnet-on-besu-and-teku-client-pairs",
- "sourceId": "EAABPS",
- "title": "Native Implementation of Ephemery Testnet on Besu & Teku Client Pairs",
- "description": "This presentation covers the work done to enable native support for Ephemery on Teku and Besu clients. Ephemery is a short-lived, resettable testnet designed to automatically revert to its genesis state after a defined period, making it ideal for intensive, short-term testing without concerns over issues like insufficient testnet funds, inactive validators, or state bloat that long-running testnets often face.",
- "track": "[CLS] EPF Day",
+ "id": "neuroai-for-ai-safety",
+ "sourceId": "ANUNJW",
+ "title": "NeuroAI for AI safety",
+ "description": "Powerful unaligned AIs pose risks to humans. This talk will explore how neuroscience-inspired AI–or NeuroAI–can lead to a deeper understanding of the human brain, and help us build more secure AI. I’ll connect these ideas to d/acc, arguing that neuroAI can play an enabling role in creating technologies that are inherently defense-favoring and promote human well-being.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Academic",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Consensus",
- "Developer Infrastructure",
- "User Experience"
- ],
"keywords": [
- "Client Development",
- "Teku",
- "Besu",
- "Ephemery"
+ "d/acc"
],
- "duration": 847,
+ "tags": [],
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "eciNYIzb7gE",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67347bee9dbb7a90e163940f.vtt",
- "transcript_text": " Hello everyone. How are you guys doing today? I hope you're having a great time at DEF CON. Okay, so today I'm going to be talking about native implementation of ephemerate testnet on client pairs, Terco and Bessu. First of all, I'm Glory, and I would like to ask this question. How many of us have heard of the word Ephemery Testnet before now? Okay, so those people that raised their hand are people in the fellowship. So that means we still have so many persons that are here to know about Ephemery. I remember when I started working on this project, my mentors, the guys from Techco and Best Studio, were like, what is ephemeris? I've not heard of it before. So I had to start explaining. I had to share the link to the documentation for them to go through it. OK, so with that being said, um. OK. That being said... All right, so why they're trying to work on it. First of all, what is ephemery? Ephemery is a resettable short-term-based testnet. So when we say it's resettable, it gets to reset itself after a given period of time. So it's not like the regular testnets that we are used like Sepolia or LISC-E and the rest of them. So eFirmary is kind of dynamic and not like the others like I said. So I wouldn't really want to go deep into eFirmary, so I'll just be diving into what I actually worked on. So yeah, for the project, the goal of the project was for me to implement or create native support for ephemery on Besso and Circle clients. And why was this needed? We realized that just like I asked, most of you didn't know about ephemery. So ephemery is still pretty new, and we are trying to see how we can get more clients and more people to know about it and to start using it. So we want to improve the user adoption and we want more clients to be running on eFirmware natively without having to go into the manual process of setting it up. So based on the work that I've done, initially when I started this project I noticed there are some work that I've done before in the past by some other fellows and at that time we had support for Forget, Red and Lighthouse and Luster so work has started for these clients. I don't think they are completed yet but as at the time I came in I noticed there was no native support for Teco. So for that, we needed to download the Genesys SSD files and the Genesys files and all of that to do those processes manually when trying to run the node. So to avoid that headache, we decided to implement native support for it. And what does that really mean when we talk about native support? We want a situation whereby when you are trying to run a node, you can easily do something like besu-network-efermary, just like you do with other supported clients like Sepulia and the rest. So because efermary is quite different, the process of implementing it on clients was not as straightforward like with other clients. So we needed to do things like trying to write some custom functions or some custom classes as well to be able to work on the updating of the genesis state and all that. So because we understand that ephemeris updates after a certain period of time, so there was need for a custom function to be created for that to be able to happen dynamically. So these were some of the things I did. Okay, so for the ephemeris genesis 5, I noticed the way it is structured when I checked the original repository, it was quite different from what Best to Clients was expecting. So I had to make some changes like other things like the S-Arch, the discovery nodes and the boot nodes to the Genesis file itself. And also I updated the documentation when I was done with the work so that when you go to their documentation now, you can see, just like you see Sepulia Oliske on their doc, you can see a family there and know the right command for you to run to be able to do that. And with this, we also implemented some testing because every aspect of this project, with the way BestESU client works, everything you do you have to write tests for it. So every implementation work done here was also properly tested. And so for TEKU we did similar stuff but with TEKU, you know, for the CL clients we don't use the normal JSON format file for the genesis so it was SSE and it and it's not as easy to manipulate as you do with the genesis format file. So with that, we needed to take a different approach and see how we can load the ssd file from the ephemera repository to get the updated states at every given point in time. So the same thing applies with Tecku. We also created a custom class and function to be able to update the Genesys states at every given point in time dynamically. So if you're running the node, you're able to get the updated states every time, so you don't need to go to the ephemeral website to go download it and use on your system. And also with Tecku, I worked on the reset feature, which means if you are running a node, you don't have to stop the node manually. So go delete your database and all of those stuff. When it's due for resets, it resets itself and then deletes all the necessities that needs to be deleted in the DB. Yeah, so pretty much like I said earlier, there's not much difference between the implementation on Serco and Bessu, just some different files and changes that were made, which was not exactly the same thing. And then the SSE file I mentioned and Genesis file and all of that. OK, so yeah, so this is like a summary of everything I did on the implementation for Terco and BESU. I completed the initial research, then created a custom function for ephemera on both BESU and the Terco clients, and then right now you can have native support on both then right now you can have, right now we have native support on both clients, so you can use the flag, the native flag like BESU.network.fmri or Terco.network.fmri and you can do that as well. And then the documentations are also properly updated and we have suitable tests for all of this. So in summary, for the whole period of the fellowship, I was able to get up to 15 PROs merged and currently have one PRO that I'm still working on and one open issue. So as far as work in progress goes, based on what I planned to do during the course of the fellowship, I wasn't able to get to the point where I was able to work on the reset feature. So right now I still have the reset feature to implement on BESU, and then as far as the website goes, I'm still yet to work on that, just redesigning the website and the tutorial work through, which I plan to do, but I didn't have enough time to do that before now. For the challenges, these are some of the challenges I faced. This was my first time working on protocol development. Before now, I do normal application level development. I write in smart contracts, doing dabs and all that. So this was my first time. And it was a lot of learning process. Had to learn about the protocol, CL, EL. And that was one thing I love about this project, because it gave me the opportunity to learn about those different areas. And then trying to understand the code base for each of these clients was another big problem. It wasn't even writing the code itself, but going through their code base, trying to figure out where my implementation is going to be, those were some of the challenges I had. But thankfully enough, I had good mentors who were able to help me navigate that. So for the future of the project, I plan to continue my work on the BESU client to complete the research future and to also implement there's still some little work I need to do on TEKU for the validator clients on slots processing and then to expand the support to other clients. So right now, we have some clients that don't currently have native supports. So my plan is to continue working and to extend support to those other clients, and also to become a validator, an ephemera validator. So key takeaways for me, this program has given me the opportunity to dive into the Ethereum protocol itself, which was one of the reasons I joined. And then I've had the opportunity to learn a lot about what the protocol entails, client implementation, what the different clients we have in the Ethereum protocol and all of that. And then before now, I do Java. Java was actually like my very first programming language when I started. But I've not done it for like more than four years or so. But with this project, I've come back to Java. And I was able to like improve on my skills as far as Java goes, as well as testing and all that. Then for EIP, I've not actually implemented anything working with an EIP before, but this project actually gave me the opportunity to write code following an EIP, so that was really good for me. Yeah, so for my mentor, special thanks to Paul Harris from the TECO team. Unfortunately, they are not here right now. And then, thanks to Sally from the BESO team. Thanks to Mario and PK910 from the eFMRI team and the past fellow, Oli. When I started I asked her some few questions and she also shared some of her past updates with me which was really helpful as well. And thanks to Josh and Mario once again for the opportunity and for setting this fellowship up. So before I go, I'd like to encourage anyone here that wants to, that is considering contributing to ephemeric. So if you want to do that, you can do that in different ways by you can be a node runner, you can implement on client, like I mentioned can be a node runner, you can implement on client, like I mentioned earlier, we still have some client that need implementation, and then you can, if you're a dApp developer, you can deploy to, you can deploy to a family test net on your dApp and run a test and see how it goes, and if you run node, you can also run, sorry, if you run infrastructure, you can run an infrastructure, and if you have any idea or whatever, you can communicate with us to learn more. Okay, so about this, so there's currently an incentivization program on eFemery that gives you an opportunity to contribute and also get incentivized for it. So, okay, let me not be fast to remove it. So in case you want to scan it, you can quickly scan it before I remove the slide. All right. So, yeah, so this is like summary of the work that has been done and what is yet to be done in terms of client implementation. So that's for EL clients, and then this is also for the CL clients. And for resources, if you want to learn more about Ephemery, you can check Ephemery.dev. And to join the community, you can check the Ephemery Metrics community. Thank you very much. All right. Thank you, Glory. Any questions for Glory about her work on the Ephemery testnet implementations? I wonder, is it something different to become a ephemer-e validator? No, no, it's not. The same way you are validator for that network, you can do the same for ephemer validator? No, no, it's not. The same way you are validator for that network, you can do the same for ephemer. So you still need 32Es? So I didn't get asked. You still need 32Es? Ephemer, yes. Oh, okay. Anyone else? Yeah, not really a question, just a comment. Like, a huge thank you. I mean, many, many thanks for all your work on ephemera. Like, it's an incredible job what you've done, implementing it and fully merging it and have it usable in both clients. It's incredible. Thank you so much for mentioning all the resources, the incentivization program. And, yeah, like, anybody can run a validator because being reset every month, resources, the incentivization program. And yeah, like anybody can run a validator because being reset every month, FMRI has infinite ETH for you, so you can just run as many validators as possible, maybe even more than mainnet at one point. But yeah, thank you so much, Glory. FMRI was created basically at DEF CON two years ago, and now after two years, it's amazing to see such an amazing job being done on the network. So yeah,",
- "eventId": "devcon-7",
- "slot_start": 1731484800000,
- "slot_end": 1731485700000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/18GeJQc_Z-ecQcsBsDbtRfawOuvBvptEDPby_7BDdqUU",
- "resources_slides": null,
"speakers": [
- "glory-justin"
- ]
+ "patrick-mineault"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731556680000,
+ "slot_end": 1731557160000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1c6dtMFBwrLngeeenxxoRO7mPchxToNPT-x38ox27h0o"
},
"vector": [
0,
+ 6,
0,
0,
0,
@@ -532867,7 +531740,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -533338,9 +532210,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -533609,7 +532481,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -533620,7 +532491,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -533658,7 +532528,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -534169,7 +533038,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -534179,6 +533047,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -534187,42 +533056,33 @@
},
{
"session": {
- "id": "navigating-developer-liability-in-open-source-code",
- "sourceId": "EXNLU9",
- "title": "Navigating Developer Liability in Open-Source Code",
- "description": "In software development, open-source code has become a cornerstone of innovation and collaboration. However, with this comes the issue of developer liability. As seen by the Tornado Cash case, developers and users can be held liable for how open-source code is used, showing the need for developers to be aware of, and navigate, the legal landscape to mitigate potential risks. This session will demystify the legal implications for developers contributing to and using open-source code projects.",
- "track": "Coordination",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Developer",
+ "id": "neurons-to-networks-whole-brain-emulation",
+ "sourceId": "ZMP7AG",
+ "title": "Neurons to Networks: Whole Brain Emulation",
+ "description": "The pursuit of whole brain emulation (WBE) represents one of humanity's most ambitious scientific endeavors, requiring unprecedented coordination between neuroscience, computer science, and institutional frameworks. This talk examines the evolving landscape of WBE research through the lens of institutional support mechanisms, with particular focus on the pioneering role of the Foresight Institute in fostering early discourse around brain emulation technologies (Fellowships, Prizes, Grants)",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "developer",
- "liability"
- ],
+ "keywords": [],
"tags": [
- "DevEx",
- "Open Source Software",
- "Regulation",
- "developer",
- "liability",
- "DevEx",
- "Open Source Software",
- "Regulation"
+ "DeSci"
],
"language": "en",
"speakers": [
- "eva-wong"
+ "niamh"
],
"eventId": "devcon-7",
- "slot_start": 1731651000000,
- "slot_end": 1731652800000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1FCTkULbE1nJ5N4av3cRDnv1nW2exLL3rZv06S06zjGU"
+ "slot_start": 1731555480000,
+ "slot_end": 1731555960000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/10jF6UddyGhtID4JHs8yJOU2RqS0OrJMOgHWiqU5tBx0"
},
"vector": [
0,
+ 6,
0,
0,
0,
@@ -534233,7 +533093,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -534709,9 +533568,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -535004,7 +533863,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -535072,7 +533930,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -535081,7 +533938,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -535108,6 +533964,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -535149,7 +534006,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -535399,7 +534255,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -535535,10 +534390,10 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
0,
0,
2,
@@ -535552,47 +534407,35 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "navigating-stablecoin-yields-and-risks",
- "sourceId": "YT9SMK",
- "title": "Navigating Stablecoin Yields and Risks",
- "description": "This panel brings DeFi experts together to discuss stablecoin risks, including economic risks related to stabilisation methods, technical risks of smart contracts, and regulatory challenges. We will discuss solutions that can help mitigate risks in this rapidly evolving space and the challenges of promoting risk-driven decisions over trend-driven ones.",
- "track": "Cryptoeconomics",
- "type": "Panel",
- "expertise": "Intermediate",
+ "id": "neurotech-humanitys-next-frontier",
+ "sourceId": "GMSXUV",
+ "title": "Neurotech - humanity’s next frontier",
+ "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Stablecoin",
- "DeFi"
- ],
- "tags": [
- "Frameworks",
- "Best Practices",
- "defi",
- "Best Practices",
- "Frameworks"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
"speakers": [
- "ariah-klages-mundt",
- "tammy-yang",
- "alessandro-buser",
- "colin-platt"
+ "juan-benet"
],
"eventId": "devcon-7",
- "slot_start": 1731488400000,
- "slot_end": 1731492000000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/15OlMPy7qIjacZlozudJLl0FrCp0kPt_kx5nIRNHipwE"
+ "slot_start": 1731555000000,
+ "slot_end": 1731555480000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/17GDo2qkBsW9cNEfQVEMckFKyyYZZ0KEwY1Wo37pv0iM"
},
"vector": [
- 0,
0,
6,
0,
@@ -536080,9 +534923,9 @@
0,
0,
0,
- 6,
- 6,
- 6,
+ 0,
+ 0,
+ 0,
6,
0,
0,
@@ -536375,7 +535218,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -536449,7 +535291,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -536535,7 +535376,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -536905,9 +535745,10 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
+ 0,
0,
2,
0,
@@ -536927,29 +535768,27 @@
},
{
"session": {
- "id": "neuroai-for-ai-safety",
- "sourceId": "ANUNJW",
- "title": "NeuroAI for AI safety",
- "description": "Powerful unaligned AIs pose risks to humans. This talk will explore how neuroscience-inspired AI–or NeuroAI–can lead to a deeper understanding of the human brain, and help us build more secure AI. I’ll connect these ideas to d/acc, arguing that neuroAI can play an enabling role in creating technologies that are inherently defense-favoring and promote human well-being.",
+ "id": "neurotechnology-opportunities-and-challenges",
+ "sourceId": "EJZNQX",
+ "title": "Neurotechnology: Opportunities and Challenges",
+ "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
"track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Academic",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "d/acc"
- ],
+ "keywords": [],
"tags": [],
"language": "en",
"speakers": [
- "patrick-mineault"
+ "milan-cvitkovic"
],
"eventId": "devcon-7",
- "slot_start": 1731556680000,
- "slot_end": 1731557160000,
+ "slot_start": 1731555960000,
+ "slot_end": 1731556680000,
"slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1c6dtMFBwrLngeeenxxoRO7mPchxToNPT-x38ox27h0o"
+ "resources_presentation": "https://docs.google.com/presentation/d/1SnBZ54kfiM59nvSu08JQKHZSM7N-GjLiVE_3-95veIw"
},
"vector": [
0,
@@ -537420,32 +536259,30 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 6,
0,
0,
0,
@@ -538268,6 +537105,7 @@
2,
0,
0,
+ 2,
0,
0,
0,
@@ -538278,8 +537116,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0
@@ -538287,35 +537123,40 @@
},
{
"session": {
- "id": "neurons-to-networks-whole-brain-emulation",
- "sourceId": "ZMP7AG",
- "title": "Neurons to Networks: Whole Brain Emulation",
- "description": "The pursuit of whole brain emulation (WBE) represents one of humanity's most ambitious scientific endeavors, requiring unprecedented coordination between neuroscience, computer science, and institutional frameworks. This talk examines the evolving landscape of WBE research through the lens of institutional support mechanisms, with particular focus on the pioneering role of the Foresight Institute in fostering early discourse around brain emulation technologies (Fellowships, Prizes, Grants)",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "Beginner",
+ "id": "next-generation-amms-eliminating-lvr",
+ "sourceId": "8DCP9K",
+ "title": "Next Generation AMMs - Eliminating LVR",
+ "description": "Loss-Versus-Rebalancing (LVR) is the most significant form of MEV, yet it has the fewest solutions addressing it. LVR remains a significant challenge for AMMs. This session delves into a comprehensive analysis of how CoW AMM addresses the problem of LVR through its unique batch mechanism. Drawing from 9 months of empirical data, the talk will explore the effectiveness of CoW AMM in mitigating LVR and offer insights into the impact of LVR resistant design on trading outcomes and market efficiency",
+ "track": "Cryptoeconomics",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
+ "keywords": [
+ "LVR"
+ ],
"tags": [
- "DeSci"
+ "MEV",
+ "AMMs",
+ "lvr",
+ "AMMs",
+ "MEV"
],
"language": "en",
"speakers": [
- "niamh"
+ "anna-george"
],
"eventId": "devcon-7",
- "slot_start": 1731555480000,
- "slot_end": 1731555960000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/10jF6UddyGhtID4JHs8yJOU2RqS0OrJMOgHWiqU5tBx0"
+ "slot_start": 1731564000000,
+ "slot_end": 1731565800000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Zivx1-urETlnczibMYsiNyH4-ey3zg3vSAD7YDHJeJk"
},
"vector": [
- 0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -539064,6 +537905,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -539144,6 +537986,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -539198,11 +538041,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -539490,6 +538328,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -539625,9 +538464,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
2,
@@ -539647,31 +538486,37 @@
},
{
"session": {
- "id": "neurotech-humanitys-next-frontier",
- "sourceId": "GMSXUV",
- "title": "Neurotech - humanity’s next frontier",
- "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "",
+ "id": "next-generation-based-rollups-a-practical-approach-to-unifying-ethereum",
+ "sourceId": "GHVK8E",
+ "title": "Next Generation Based Rollups: A Practical Approach to Unifying Ethereum",
+ "description": "I plan to speak on the concept of based sequencing (based rollups). I want to not only introduce the concept but also explain recent developments (what I like to call next generation based rollups). This includes based preconfirmations, fast->realtime proving, customizable composability, practical synchronous composability, among others. I will introduce I also plan to provide a brief summary to my Bankless Summit talk on ETH value accrual in the presence of based rollups.",
+ "track": "Layer 2",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "based rollups",
+ "sequencing",
+ "composability"
+ ],
+ "tags": [
+ "Fragmentation",
+ "Frameworks",
+ "Layer 2s"
+ ],
"language": "en",
"speakers": [
- "juan-benet"
+ "mteam"
],
"eventId": "devcon-7",
- "slot_start": 1731555000000,
- "slot_end": 1731555480000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/17GDo2qkBsW9cNEfQVEMckFKyyYZZ0KEwY1Wo37pv0iM"
+ "slot_start": 1731642600000,
+ "slot_end": 1731644400000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Ftf3rfy0W2vOu0uKzcm-Qyqhd_eURotVsS5HzTB9jFw"
},
"vector": [
- 0,
- 6,
0,
0,
0,
@@ -539679,6 +538524,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -540463,6 +539309,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -540485,6 +539332,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -540523,12 +539371,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -540987,6 +539830,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -541005,31 +539849,36 @@
},
{
"session": {
- "id": "neurotechnology-opportunities-and-challenges",
- "sourceId": "EJZNQX",
- "title": "Neurotechnology: Opportunities and Challenges",
- "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "",
- "audience": "Engineering",
+ "id": "non-native-arithmetic-via-crt-codes",
+ "sourceId": "B7CJU8",
+ "title": "Non-Native Arithmetic via CRT Codes",
+ "description": "Non-native arithmetic is an important and costly operation in SNARKs. It is essential for proving validity of general cryptographic data like RSA signatures, non-native elliptic curve arithmetic like secp256r1, and general SNARK proof composition. We investigate a new approach to prove non-native integer arithmetic using Residue Number Systems and a batch proximity test for Chinese Remainder Theorem (CRT) codes, as well as surprising connections to STARK soundness.",
+ "track": "Applied Cryptography",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Coding Theory",
+ "Math"
+ ],
+ "tags": [
+ "Cryptography",
+ "SNARK",
+ "Zero-Knowledge"
+ ],
"language": "en",
"speakers": [
- "milan-cvitkovic"
+ "liam-eagen"
],
"eventId": "devcon-7",
- "slot_start": 1731555960000,
- "slot_end": 1731556680000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1SnBZ54kfiM59nvSu08JQKHZSM7N-GjLiVE_3-95veIw"
+ "slot_start": 1731576600000,
+ "slot_end": 1731578400000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/15NH3bC1NnjmkyRycEK1VaWR9dgZMJsH0PJMf-OTgOyA"
},
"vector": [
- 0,
- 6,
0,
0,
0,
@@ -541040,6 +539889,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -541790,6 +540640,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -542057,9 +540909,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -542344,7 +541194,6 @@
0,
2,
0,
- 0,
2,
0,
0,
@@ -542357,44 +541206,42 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "new-account-types-novel-user-flows-but-what-do-they-look-like-breaking-changes-to-ux-in-a-post-7702-world",
- "sourceId": "P9FRCH",
- "title": "New account types = novel user flows, but what do they look like? Breaking changes to UX in a post-7702 world",
- "description": "The wallet world has evolved to embrace contract accounts (4337 and 7702), app-owned wallets, session keys (CAIP-25), and permissions controls (7715). How might we on the app layer design and build upon these new account types? In this talk, I will demonstrate the possibilities for novel user flows given these new account standards, compare how these new standards can introduce pitfalls, and provide best practices on how to design for app layer in a post-7702 world.",
- "track": "Usability",
+ "id": "onchain-capital-allocation-from-current-mechanisms-to-future-possbilities",
+ "sourceId": "BEWPLY",
+ "title": "Onchain Capital Allocation: From current mechanisms to future possbilities",
+ "description": "Capital allocation, from paying bills to complex organizational funding, often suffers from inefficiencies and lack of transparency. Web3 has the potential to revolutionize this by enabling more efficient, effective, and transparent capital distribution. By addressing coordination failures and introducing new onchain strategies, crypto could transform how society allocates resources.\r\n\r\nGitcoin founder Kevin Owocki will articulate this design space in this 20 minute talk.",
+ "track": "Coordination",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Design",
- "featured": false,
+ "audience": "Research",
+ "featured": true,
"doNotRecord": false,
"keywords": [
- "Wallet",
- "UX"
+ "Mycofi"
],
"tags": [
- "ux",
- "wallet",
- "Account Abstraction",
- "Design",
- "Key Management",
- "UI/UX"
+ "Quadratic Voting",
+ "Public good",
+ "Regenerative Applications",
+ "mycofi",
+ "Public good",
+ "Quadratic Voting",
+ "Regenerative Applications"
],
"language": "en",
"speakers": [
- "gregthegreek",
- "cindy"
+ "kevin-owocki"
],
"eventId": "devcon-7",
- "slot_start": 1731573000000,
- "slot_end": 1731574800000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1igvH4fHKFwKho-LbIvoWNBLHx_rza8WlcSOHkION9JE"
+ "slot_start": 1731391200000,
+ "slot_end": 1731393000000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1-hdTt4ELigY4Pe3nCr4vnQFCDtQaHLB_e-UaHGdXucE"
},
"vector": [
0,
@@ -542405,6 +541252,9 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
6,
0,
0,
@@ -542669,6 +541519,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -542893,8 +541744,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -543200,7 +542049,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -543208,7 +542056,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -543255,6 +542102,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -543276,6 +542124,11 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -543292,7 +542145,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -543350,6 +542202,22 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -543551,6 +542419,22 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -543575,46 +542459,6 @@
0,
0,
0,
- 2,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -543715,6 +542559,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -543725,48 +542570,48 @@
0,
0,
0,
- 2,
0,
0
]
},
{
"session": {
- "id": "next-generation-amms-eliminating-lvr",
- "sourceId": "8DCP9K",
- "title": "Next Generation AMMs - Eliminating LVR",
- "description": "Loss-Versus-Rebalancing (LVR) is the most significant form of MEV, yet it has the fewest solutions addressing it. LVR remains a significant challenge for AMMs. This session delves into a comprehensive analysis of how CoW AMM addresses the problem of LVR through its unique batch mechanism. Drawing from 9 months of empirical data, the talk will explore the effectiveness of CoW AMM in mitigating LVR and offer insights into the impact of LVR resistant design on trading outcomes and market efficiency",
- "track": "Cryptoeconomics",
+ "id": "onchain-is-the-next-online",
+ "sourceId": "CXZ7UT",
+ "title": "Onchain is the next online",
+ "description": "The goal is to bring the world into a global onchain economy that increases innovation, creativity, and freedom — and that's only possible on a decentralized platform that’s super easy to use. In this talk, Jesse Pollak, Creator of Base, can share his insights on why building for simplicity is so important for the Ethereum ecosystem, and what he’s learned from building the fastest-growing L2.",
+ "track": "Usability",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "expertise": "Beginner",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "LVR"
+ "Account Abstraction",
+ "Layer 2s",
+ "UX",
+ "Wallets",
+ "Developer Tools"
],
"tags": [
- "MEV",
- "AMMs",
- "lvr",
- "AMMs",
- "MEV"
+ "Layer 2s",
+ "Account Abstraction",
+ "Paymaster",
+ "creators",
+ "Account Abstraction",
+ "Layer 2s"
],
"language": "en",
"speakers": [
- "anna-george"
+ "jesse-pollak"
],
"eventId": "devcon-7",
- "slot_start": 1731564000000,
- "slot_end": 1731565800000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1Zivx1-urETlnczibMYsiNyH4-ey3zg3vSAD7YDHJeJk"
+ "slot_start": 1731641400000,
+ "slot_end": 1731643200000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1-gQZPtDYukgyGQgCLVng3phznkejfM-uJlR1MDiF-MQ"
},
"vector": [
- 0,
- 0,
- 6,
- 0,
0,
0,
0,
@@ -543775,6 +542620,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -544517,7 +543363,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -544567,6 +543412,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -544580,6 +543427,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -544598,7 +543446,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -544941,10 +543788,11 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -545080,7 +543928,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -545092,41 +543939,49 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "next-generation-based-rollups-a-practical-approach-to-unifying-ethereum",
- "sourceId": "GHVK8E",
- "title": "Next Generation Based Rollups: A Practical Approach to Unifying Ethereum",
- "description": "I plan to speak on the concept of based sequencing (based rollups). I want to not only introduce the concept but also explain recent developments (what I like to call next generation based rollups). This includes based preconfirmations, fast->realtime proving, customizable composability, practical synchronous composability, among others. I will introduce I also plan to provide a brief summary to my Bankless Summit talk on ETH value accrual in the presence of based rollups.",
- "track": "Layer 2",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "open-challenges-in-mini-apps-and-frames",
+ "sourceId": "TZDRPY",
+ "title": "Open challenges in Mini-apps and Frames",
+ "description": "There are a number of open challenges we've run into with trying to make interoperable mini-apps work at Open Frames. I'll run through some of them and what I think it'll take to get great UX via Mini-apps.",
+ "track": "Usability",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "based rollups",
- "sequencing",
- "composability"
- ],
"tags": [
- "Fragmentation",
- "Frameworks",
- "Layer 2s"
+ "Social",
+ "UI/UX",
+ "frames",
+ "Social",
+ "UI/UX"
],
- "language": "en",
- "speakers": [
- "mteam"
+ "keywords": [
+ "frames"
],
+ "duration": 480,
+ "language": "en",
+ "sources_swarmHash": "e0544223cf89ff9bbe7b382237527d59d6ad4ad2e377f957869ce72df0c49fbe",
+ "sources_youtubeId": "xoMfU9Gk0xc",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731642600000,
- "slot_end": 1731644400000,
+ "slot_start": 1731400200000,
+ "slot_end": 1731400800000,
"slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1Ftf3rfy0W2vOu0uKzcm-Qyqhd_eURotVsS5HzTB9jFw"
+ "resources_presentation": "https://docs.google.com/presentation/d/10NeCTKHHZ_IznsD0BVvBmKLhLozti5XPFkZHUhhk45M",
+ "resources_slides": null,
+ "speakers": [
+ "david-furlong"
+ ]
},
"vector": [
0,
@@ -545136,11 +543991,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -545924,8 +544776,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -545942,12 +544792,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -545986,7 +544836,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -546064,6 +544913,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -546312,6 +545162,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -546442,7 +545293,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -546452,6 +545302,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -546464,37 +545316,31 @@
},
{
"session": {
- "id": "non-native-arithmetic-via-crt-codes",
- "sourceId": "B7CJU8",
- "title": "Non-Native Arithmetic via CRT Codes",
- "description": "Non-native arithmetic is an important and costly operation in SNARKs. It is essential for proving validity of general cryptographic data like RSA signatures, non-native elliptic curve arithmetic like secp256r1, and general SNARK proof composition. We investigate a new approach to prove non-native integer arithmetic using Residue Number Systems and a batch proximity test for Chinese Remainder Theorem (CRT) codes, as well as surprising connections to STARK soundness.",
- "track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Expert",
- "audience": "Research",
+ "id": "open-decentralized-ai",
+ "sourceId": "WDMSDF",
+ "title": "Open + Decentralized AI",
+ "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Coding Theory",
- "Math"
- ],
- "tags": [
- "Cryptography",
- "SNARK",
- "Zero-Knowledge"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
"speakers": [
- "liam-eagen"
+ "emad-mostaque"
],
"eventId": "devcon-7",
- "slot_start": 1731576600000,
- "slot_end": 1731578400000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/15NH3bC1NnjmkyRycEK1VaWR9dgZMJsH0PJMf-OTgOyA"
+ "slot_start": 1731580800000,
+ "slot_end": 1731581400000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/185D2a1dcM0Mnygg246mzs0j_kcxYkRpeWxUnWh_d0cs"
},
"vector": [
0,
+ 6,
0,
0,
0,
@@ -546504,7 +545350,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -546991,10 +545836,58 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -547258,8 +546151,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -547528,55 +546419,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -547808,11 +546650,11 @@
0,
0,
0,
+ 2,
0,
0,
2,
0,
- 2,
0,
0,
0,
@@ -547829,37 +546671,25 @@
},
{
"session": {
- "id": "onchain-capital-allocation-from-current-mechanisms-to-future-possbilities",
- "sourceId": "BEWPLY",
- "title": "Onchain Capital Allocation: From current mechanisms to future possbilities",
- "description": "Capital allocation, from paying bills to complex organizational funding, often suffers from inefficiencies and lack of transparency. Web3 has the potential to revolutionize this by enabling more efficient, effective, and transparent capital distribution. By addressing coordination failures and introducing new onchain strategies, crypto could transform how society allocates resources.\r\n\r\nGitcoin founder Kevin Owocki will articulate this design space in this 20 minute talk.",
- "track": "Coordination",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
- "featured": true,
+ "id": "open-source-orchestra-coffee-shop-welcome",
+ "sourceId": "RKELBQ",
+ "title": "Open-Source Orchestra coffee shop welcome",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
+ "featured": false,
"doNotRecord": false,
- "keywords": [
- "Mycofi"
- ],
- "tags": [
- "Quadratic Voting",
- "Public good",
- "Regenerative Applications",
- "mycofi",
- "Public good",
- "Quadratic Voting",
- "Regenerative Applications"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "kevin-owocki"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731391200000,
- "slot_end": 1731393000000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1-hdTt4ELigY4Pe3nCr4vnQFCDtQaHLB_e-UaHGdXucE"
+ "slot_start": 1731636000000,
+ "slot_end": 1731639600000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1DTTbLibZzh-i4lar_fk3TZfYIUaEw5RUPBHEEHYhGG0"
},
"vector": [
0,
@@ -547871,9 +546701,9 @@
0,
0,
0,
+ 6,
0,
0,
- 6,
0,
0,
0,
@@ -548138,7 +546968,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -548723,7 +547552,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -548745,7 +547573,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -548823,7 +547650,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -549044,7 +547870,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -549175,10 +548000,11 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
+ 0,
0,
2,
0,
@@ -549192,45 +548018,40 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "onchain-is-the-next-online",
- "sourceId": "CXZ7UT",
- "title": "Onchain is the next online",
- "description": "The goal is to bring the world into a global onchain economy that increases innovation, creativity, and freedom — and that's only possible on a decentralized platform that’s super easy to use. In this talk, Jesse Pollak, Creator of Base, can share his insights on why building for simplicity is so important for the Ethereum ecosystem, and what he’s learned from building the fastest-growing L2.",
- "track": "Usability",
- "type": "Talk",
+ "id": "open-source-orchestra-zukaraoke-ktv",
+ "sourceId": "JBCULT",
+ "title": "Open Source Orchestra - ZuKaraoke KTV",
+ "description": "OSO brings karaoke to Devcon!",
+ "track": "Entertainment",
+ "type": "Music",
"expertise": "Beginner",
- "audience": "Developer",
+ "audience": "Hobby",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Account Abstraction",
- "Layer 2s",
- "UX",
- "Wallets",
- "Developer Tools"
+ "Music",
+ "Karaoke"
],
"tags": [
- "Layer 2s",
- "Account Abstraction",
- "Paymaster",
- "creators",
- "Account Abstraction",
- "Layer 2s"
+ "Art",
+ "Free Speech",
+ "Social"
],
"language": "en",
"speakers": [
- "jesse-pollak"
+ "veronica"
],
"eventId": "devcon-7",
- "slot_start": 1731641400000,
- "slot_end": 1731643200000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1-gQZPtDYukgyGQgCLVng3phznkejfM-uJlR1MDiF-MQ"
+ "slot_start": 1731562200000,
+ "slot_end": 1731564000000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1LRNlRRa-nWIkUZN0OzhHcccD4YwYKnOZT21n-IMTU0Q"
},
"vector": [
0,
@@ -549241,11 +548062,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -550012,6 +548830,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -550036,7 +548855,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -550051,7 +548869,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -550094,6 +548911,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -550165,6 +548983,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -550416,8 +549236,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -550552,12 +549370,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -550568,44 +549386,33 @@
},
{
"session": {
- "id": "open-challenges-in-mini-apps-and-frames",
- "sourceId": "TZDRPY",
- "title": "Open challenges in Mini-apps and Frames",
- "description": "There are a number of open challenges we've run into with trying to make interoperable mini-apps work at Open Frames. I'll run through some of them and what I think it'll take to get great UX via Mini-apps.",
- "track": "Usability",
- "type": "Lightning Talk",
+ "id": "open-tech-blockchain-and-settlement",
+ "sourceId": "NGXHAA",
+ "title": "Open Tech, Blockchain, and Settlement",
+ "description": "In this talk, we discuss the what and why of open tech, starting with networking and the internet. Using the recurring progression of tech to openness, we explore the critical classes of commitments and settlement that enable blockchain to accelerate open coordination of finances, tech, and society.",
+ "track": "Coordination",
+ "type": "Talk",
"expertise": "Beginner",
- "audience": "Product",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Social",
- "UI/UX",
- "frames",
- "Social",
- "UI/UX"
- ],
"keywords": [
- "frames"
+ "Forking"
+ ],
+ "tags": [
+ "fork",
+ "Consensus",
+ "Coordination"
],
- "duration": 480,
"language": "en",
- "sources_swarmHash": "e0544223cf89ff9bbe7b382237527d59d6ad4ad2e377f957869ce72df0c49fbe",
- "sources_youtubeId": "xoMfU9Gk0xc",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731400200000,
- "slot_end": 1731400800000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/10NeCTKHHZ_IznsD0BVvBmKLhLozti5XPFkZHUhhk45M",
- "resources_slides": null,
"speakers": [
- "david-furlong"
- ]
+ "robert-drost"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731558600000,
+ "slot_end": 1731560400000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1pAUfWWkDdvSVfjG3UFm9ChrQDu1XE0Ae1vmkkLNxV3A"
},
"vector": [
0,
@@ -550616,13 +549423,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -551365,6 +550169,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -551419,7 +550224,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -551515,6 +550319,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -551540,7 +550345,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -551790,10 +550594,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -551925,11 +550729,11 @@
0,
2,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -551943,12 +550747,12 @@
},
{
"session": {
- "id": "open-decentralized-ai",
- "sourceId": "WDMSDF",
- "title": "Open + Decentralized AI",
- "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
+ "id": "opening-ceremony",
+ "sourceId": "X3JSYF",
+ "title": "Opening Ceremony",
+ "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
"expertise": "",
"audience": "Engineering",
"featured": false,
@@ -551957,15 +550761,22 @@
"tags": [],
"language": "en",
"speakers": [
- "emad-mostaque"
+ "skylar-weaver"
],
"eventId": "devcon-7",
- "slot_start": 1731580800000,
- "slot_end": 1731581400000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/185D2a1dcM0Mnygg246mzs0j_kcxYkRpeWxUnWh_d0cs"
+ "slot_start": 1731380400000,
+ "slot_end": 1731381300000,
+ "slot_roomId": "main-stage",
+ "sources_youtubeId": "dMLeSMcBskU",
+ "sources_swarmHash": "b4b199e383bcf161d7da28671901d39434e7456159cd822eaf6ccf1d802635ab",
+ "resources_presentation": "https://docs.google.com/presentation/d/1VG1PST0liQiPWvaWsw3TB7LQkH7HEEXqam66Ds4rCHw"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
6,
0,
@@ -552140,6 +550951,12 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -552469,20 +551286,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -553301,14 +552104,14 @@
},
{
"session": {
- "id": "open-source-orchestra-coffee-shop-welcome",
- "sourceId": "RKELBQ",
- "title": "Open-Source Orchestra coffee shop welcome",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "id": "opening-circle",
+ "sourceId": "T7THRV",
+ "title": "Opening Circle",
+ "description": "By master Zoe\r\n(Opening Session)\r\n- Nervous system check-in (to communicate safety and help people settle into the space)\r\n- Short check-in: guided meditation, breathwork, and gentle stretches (approx. 5 minutes) to bring everyone into the present moment\r\n- Intention setting for the conference, guiding participants to align their energy and time with their vision\r\n- Sharing intentions in small groups (3-5 people) to build community connection\r\n- Closing with a gratitude practice\r\n\r\n12 Nov 14:00 - 14:45",
"track": "Entertainment",
- "type": "Music",
- "expertise": "",
- "audience": "Engineering",
+ "type": "Mixed Formats",
+ "expertise": "Beginner",
+ "audience": "Hobby",
"featured": false,
"doNotRecord": false,
"keywords": [],
@@ -553316,10 +552119,10 @@
"language": "en",
"speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731636000000,
- "slot_end": 1731639600000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1DTTbLibZzh-i4lar_fk3TZfYIUaEw5RUPBHEEHYhGG0"
+ "slot_start": 1731394800000,
+ "slot_end": 1731397500000,
+ "slot_roomId": "decompression-room",
+ "resources_presentation": "https://docs.google.com/presentation/d/1n226DY0rUYiKnECT9xm9IZ_yu2qSeuhOfgg63eVqUM0"
},
"vector": [
0,
@@ -554634,19 +553437,16 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
- 2,
- 0,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -554657,36 +553457,55 @@
},
{
"session": {
- "id": "open-source-orchestra-zukaraoke-ktv",
- "sourceId": "JBCULT",
- "title": "Open Source Orchestra - ZuKaraoke KTV",
- "description": "OSO brings karaoke to Devcon!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "Beginner",
- "audience": "Hobby",
+ "id": "opsec-for-the-dark-forest-or-how-to-avoid-getting-rekt",
+ "sourceId": "TAEPPF",
+ "title": "OpSec for the Dark Forest (or how to avoid getting rekt)",
+ "description": "We will focus on the most important things you need to do to have a good OpSec to survive in the Crypto Dark Forest. I will cover: computer, mobile phone, email, telegram, social media, phone numbers, password managers and 2FA strategy, security software & social engineering.\r\nThis is based on many years of experience and in the cases we see daily on SEAL 911.",
+ "track": "Security",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Music",
- "Karaoke"
- ],
"tags": [
- "Art",
- "Free Speech",
- "Social"
+ "Privacy",
+ "Security",
+ "Hacks",
+ "2FA",
+ "dprk",
+ "2FA",
+ "Hacks",
+ "Privacy",
+ "Security"
],
- "language": "en",
- "speakers": [
- "veronica"
+ "keywords": [
+ "OpSec",
+ "Social Engineering",
+ "Malware",
+ "0days",
+ "DPRK"
],
+ "duration": 542,
+ "language": "en",
+ "sources_swarmHash": "0fb90958816f38c563510ad9f68ada525a114c7dbdf95c1534f4a4675a6e902c",
+ "sources_youtubeId": "nM2BBNlIRe4",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a0d3a168eb535728b37.vtt",
+ "transcript_text": " Leonardo Silva Reviewer's Reviewer's Name How are you guys? How's everything? Well, today I had a workshop, but they told me, okay, you don't have an hour, you have five minutes. So I'll make it brief, and I'll go to the conclusions. Well, I'm Pablo Sabatera. I do web-free operational security at OPSEC, where we train and audit companies for everything that is not in a smart contract. And I am a contributor of SIL 911, where we do incident response for blockchain. So what are we going to talk about today? Simple things that we can do to enhance our OPSEC, right? So one thing that is very important to know is that it's not so important if I use Windows or Mac, Android or iPhone, Chrome or Safari or whatever. The important thing is how we configure the tools that we use, right? So first thing I want to talk about very fast, two-factor authentication, things that you do not have to do, do it with SMS. And we cannot do it anymore with TOTP apps like Google Authenticator or Authy. Those kind of 2FAs can be phased and they're being phased every day. We need to use YubiKeys, right? But not the YubiKey with the normal OTP mode. YubiKey with FIDO2. That cannot be phished. This is happening a lot in the ecosystem. Next, soldier engineering. We have to be very, very, very careful for this. Like professionals hack people, not systems, right? Today is much cheaper to attack someone and much easier than to attack a system. So be very careful with supposed recruiters, VC fans, investors and journalists that want to invite you to some call or something. Never download anything. Be very careful with PDFs that you open. They are usually infected. And if someone looks, if something looks like strange, it's probably a scam, right? And everything is a scam until proven otherwise, everything. Next, eventually all of us will get hacked. That will happen. It's not a matter of it will happen or not, it's just a matter of time. So we need to be able to contain the damage so that you know when someone in your team has been hacked, the damage will be contained. Even the founders, even the CISO, even the CTO, everyone. Use an antivirus and a firewall. People think that, no, I use a Mac, I don't need an antivirus. Use an antivirus. MacBook is not good with virus alone. There is a good foundation called Objective-C that has many tools for security in Mac. One more thing, the attack will come from a trusted source, right? For example, we saw how they were hacking the Eventbrite of the events at Delcon one hour before the event, and they send a message from the real account to everyone, hey, you have to mint this NFT. You mint it, your wallet is drained completely. You receive an email that says that it's from Trezor, and it's really from Trezor, from their official system, but it has been hacked. They send you a drainer. You are done. One more thing. Use a password manager and never, never, ever reuse a password, right? But let's use password managers, and we have to have them configured very securely but never ever ever and this is very important very important never put a seed phrase in a password manager right for sure many of you have done it yeah and you say oh I did it but it's okay my password by my password manager is secure no it's not if you have ever put a seed phrase in a password manager you cannot use that wallet anymore you have ever put a seed phrase in a password manager, you cannot use that wallet anymore. You have to move to a new one. Use hardware wallets. Hardware wallets are important. Many will think, okay, these things that this guy are telling us are very basic. This basic stuff is the reason why today 85% of lost funds are lost every day, right? In blockchain. It's not anymore due to smart contracts. We have gotten very, very good at security with smart contracts. And money is being stolen like this. So you have to be really, really careful. Well, I hope you liked it. I will be here if you want to talk more about this. This was a very, very, very small resume. But operational security is important. It's the number one reason how we are being attacked by very sophisticated threat actors. Something that is happening is that in the industry, we have one of the worst objects in all the industries worldwide because we don't have regulations so any company does whatever they think that it's okay and it's not. And on the other side we have very very sophisticated threat actors from nation states that are doing this kind of attacks and they know what they're doing so be extra extra careful I hope you liked it thank you Pablo any questions for Pablo yep oh there do you want to give a go this is on your side and do you want to give it a go? Because it's on your side. Do you want to throw? I have to throw it there? You're much better than me. So what would you recommend to people to store their seed phrases securely? Because I think the challenge is, I mean, I'm a CTO as well, you either have to make it secure or you want to prevent people writing it down on a post-it note. I think that writing down seed phrases is one of the best ways to store them. One hack that you can use that is very, very simple, was told to me by one of the guys from the Red Guild, is buying anti-chambering bags, the ones that you commerce use. So you write it there, and wherever it is that you save it, you save it with that. So with that, you are sure that it has never been seen by anyone. If sometime it was seen by someone, they have to break that. So that's another very good way, and I really like Shamir, like having your seed phrase and cutting it in places in three lists, but only you need two of those three lists, that gives you confidentiality and availability. So I think that's pretty good. Thank you. Do we see any other questions? Oh, over there. There was one question. Yeah. All right. I actually wrote down my question. How do you choose a product for secrets like SSH keys, OAuth tokens, et cetera, management across multiple cloud providers? So a product for what? Sorry? A product for secrets management like SSH keys of tokens across multiple cloud providers I don't have a good answer for that. So I'm not I'm not sure what would I use? The guys that are really because I only talk about stuff I am really really good at right and the guys from the Red Guild have a very good guide on that, so they will be maybe able to ask a question from Fargo rather than me. No, thank you. Thank you. What do you think? What is the most secure, multi-sig wallet or hardware wallet? No, I think that safe is good. And regarding hardware wallets, I consider that all of them are also very good, Tresor, Ledger, SafePal. I think it's how you use them, right? But I think that all of them are very good, and I think that safe is also very, very good. Yeah, there's a question over there. You covered a lot of stuff there, but is there any advice you give on browsers or how you deal with browsers? And that's generally where a lot of stealers are sitting. Yeah, browsers, be very, very careful with the extensions you download. Like, we browsers, be very, very careful with the extensions you download. Like, we have to be very, very careful with extensions. There are lots of malicious extensions. And the other good practice is to have more than one session. For example, you use Chrome, you have five sessions, one for work, one for DeFi, one for personal stuff, one for this, one for that, for that. And you also can have another browser, right? Or even better than that is having another session in a VPN, right? So you have it, sorry, in a virtual machine. So you have another virtual machine with another browser if you want to keep it really separate, and that's also pretty good. Okay, thank you very much.",
"eventId": "devcon-7",
- "slot_start": 1731562200000,
- "slot_end": 1731564000000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1LRNlRRa-nWIkUZN0OzhHcccD4YwYKnOZT21n-IMTU0Q"
+ "slot_start": 1731405600000,
+ "slot_end": 1731406200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1jLrqWU4lm17NODOESY5ysFcreo3AXNtlq_mO-78OMZY",
+ "resources_slides": null,
+ "speakers": [
+ "pablo-sabbatella"
+ ]
},
"vector": [
+ 6,
0,
0,
0,
@@ -554696,11 +553515,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -555440,6 +554254,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -555466,7 +554281,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -555547,7 +554361,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -555557,6 +554370,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -555607,6 +554421,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -555619,7 +554434,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -555690,6 +554504,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -555870,6 +554685,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -555999,6 +554815,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -556011,8 +554828,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -556022,38 +554837,50 @@
},
{
"session": {
- "id": "opening-ceremony",
- "sourceId": "X3JSYF",
- "title": "Opening Ceremony",
- "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.",
- "track": "Real World Ethereum",
+ "id": "optimism-retro-funding-so-far-so-good-so-what",
+ "sourceId": "QCMZS8",
+ "title": "Optimism Retro Funding: So Far, So Good, So What!?",
+ "description": "So far, over 50M OP has been awarded to projects with no strings attached. So good, another 800M OP is planned for future rounds. So what ... is the impact? My talk will offer an objective, data-driven perspective on the \"so what\" of Optimism's Retro Funding. It will include analysis on how different cohorts of projects have performed longitudinally across a variety of growth and quality metrics, while controlling for different funding and market-related effects.",
+ "track": "Coordination",
"type": "Talk",
- "expertise": "",
- "audience": "Engineering",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
- "language": "en",
- "speakers": [
- "skylar-weaver"
+ "tags": [
+ "RPGF",
+ "Collective Intelligence",
+ "Open Source Software",
+ "grants",
+ "Collective Intelligence",
+ "Open Source Software",
+ "RPGF"
+ ],
+ "keywords": [
+ "Data Science",
+ "Impact Measurement",
+ "Grants"
],
+ "duration": 1542,
+ "language": "en",
+ "sources_swarmHash": "047944c236f3e1dd0245dbd16955b54f0bc3a72e7dfec5f04b2ab12b56574f74",
+ "sources_youtubeId": "MmjAhdEbnV0",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673358ad3a168eb535865df1.vtt",
+ "transcript_text": " Thanks everyone. Before getting into crypto, I did work in the coffee supply chain and I've been getting a lot of questions about where the best coffee is in Bangkok and I'm still looking for an answer. So if anybody knows where to go for some excellent specialty coffee, please hit me up. I'd love to check that out. Today I'm going to be talking about Optimism Retrofunding. It's a experimental grants program being run by the Optimism Collective. And as a data enthusiast, it creates this incredible substrate for looking at the effectiveness of different grant programs. I'm the co-founder of an organization called Open Source Observer. We're building a free analytics platform and a community of data scientists who care about measuring impact in the open. And so today we're going to be talking about the impact that Optimism is achieving and identifying some opportunities to improve and double down on where that impact has been most effective. So I guess just a quick check. How many of the people in this room are familiar with retrofunding optimism? All right, pretty good. So I have a few slides that will be a bit of a cursory introduction to optimism. I think the main point that I want to get across here is that I believe this is a really important experiment for the world to pay attention to and to understand. Regardless of whether it succeeds or fails, in the long run, there's something special and different that is happening here, and it's worth paying attention to. So another chart, or first chart of the day. We have a lot of charts coming. But it has another poll. How many of you have seen this before? How many of you are familiar with the Electric Capital Developer Report? Have you seen this? All right. Not as much awareness. This is one of the most looked at reports that the crypto industry puts out. And they track a metric called monthly active developers. They've been putting this out for quite some time now. It's basically an indicator of how many developers there are working across all of crypto, not just Ethereum. Every ecosystem is captured here. And so what you can see from this chart is that things went up a lot in 2021. They kind of plateaued in 2022. And now things have gone down in aggregate from a peak of around 30,000 to about 26,000 monthly active developers by this metric. To put this in comparison, I recently heard that Gemini, which is Google's AI platform, they have 1.5 million active developers by their count. I don't know if they're comparable, but orders of magnitude greater than what we have here across the crypto industry. Here's another metric. This one is the amount of venture capital that has gone into crypto since the beginning, basically. This chart stops at 2022, but there's another number that they care about, which is the total amount of deal flow. If we add this up, we get a number of around $80 billion has gone into the space since 2016. So I think the interesting thing is actually when you start combining these types of data sets. I don't have the ability to go in and look exactly how they calculate these things, but I can overlay the two. And when I do that, I can come up with a new metric of my own. And that metric is the dollars spent per developer retained. And what you can see here is that for every $3.1 million that has been invested prospectively as risk capital, we only have one retained developer in the industry still here to show for that. So I think we can do better, and we hope to do better. The point is not just that the venture capital can improve, but really that prospective funding is difficult. Behind every one of these deals, there's a team of professionals that are researching these companies and making bets. And the reality is that it's often quite difficult to do this. And there's an acceptance that most of these bets are not going to work out. So prospective funding is hard. Retrofunding is based on the principle that it is easier to identify something that has worked looking back than to predict it going forward. Vitalik helped design the mechanism. Optimism has been rolling it out. And it's a pretty unique way of creating markets around impact. Now to be clear I don't think the most die-in-the-wool retrofunding maxi would say that retrofunding is the only way that anything in the world should be funded but the important point here is that right now we have a surplus of, not a surplus, but a large amount of prospective funding and we need more retrospective funding in the world to signal what things we value and drive more people to build in those directions. And so that's what we'll be talking about today. At launch, Optimism allocated 850 million tokens from its treasury to retrofunding. This is a big deal. And they made a promise that if you create impact on the Optimism collective, you will be rewarded for that impact. What that impact is, how it will be rewarded, TBD, but that's what we're here to discuss. To date, optimism has deployed around 60 million OP, or at least allocated, not all that has gone out the door, which is a pretty small share of its treasury. So even though this is a large sum of tokens, we're still very much in the early innings. And each round has been designed around a specific set of experiments, hypotheses that they wanted to test. Round one, I think, was completely off chain. It was a proof of concept, about 50 projects, no applications. The selection was done, I think, by the OP Labs team. Rounds two and three are where this program gained a lot of recognition. They were big mega rounds. 40 million OP went out in total. More than 600 projects participated. There were 100 badge holders, also known as citizens, who were voting on projects. I was a badge holder. I think there are a few in the room still. But they were given this enormous task of reviewing all of these projects and identifying which ones they thought should deserve a certain amount of funding. In response to the mega rounds in 2024, this past year, optimism changed the scope a little bit and instead of having these large mega rounds, they moved to a system where you have smaller, more tightly scoped rounds with tighter eligibility criteria. And in those rounds, they also tested different experiments around badge holders and guest voters and expertise. In total, about 18 million has gone out, and there's more allocated through the end of 2024. Again, we're going to be looking at the results of the program so far, but putting this in the scale of other public goods funding experiments, this is pretty unique. It's pretty large. And my team and I at Open Source Observer, the fact that this was a real experiment of significant scale was what attracted us to want to pay attention and work at Optimism. There's a lot of economists that like writing long papers about how public goods funding is broken, but here was a real chance to throw magic internet money and test whether we could actually change the incentive landscape. So I think people should pay attention to this, regardless of whether they participate directly or not. But first, because the only thing that people like more than throwing tokens around is complaining about things on Twitter, I want to address a few myths about optimism and the program of retrofunding. So the first myth is that retrofunding comes with conditions. The reality is the projects that receive retrofunding are getting with no strings attached. They can cash out, they can migrate their projects to Solana, they can delegate to governance, or they can keep building. And what we see continuously is that most people actually tend to keep building on optimism. The second myth is that retrofunding is optimism's only grant program. This is also not true. It is also... Oops, sorry. It is not the only grants program. It's also not the largest grants program. Optimism also runs perspective funding. Since 2024, they've given out more than 60 million, I believe, in perspective mission-based grants. And most of the projects that are receiving retrofunding have also received some form, or a large number of the products that have received retrofunding have also participated in these prospective grants. I think there's a narrative that Optimism expects all of its teams to work for free and pray for retrofunding. This is not the case. There are various mechanisms and retrofunding is just one of them, and obviously the most experimental at this point. Myth number three, Optimism no longer cares about public goods. You've probably heard this before if you follow the optimism narrative on Twitter. I think this narrative really took root after optimism changed the name of the program, but the reality is that there was never a formal definition of what a public good is. Optimism and I kind of agree with this definition have always viewed it as a kind of a spectrum and the role of retrofunding is to fill the gap. It's identify where is the market not effective in rewarding impact and using tokens strategically to fill that gap. Myth number four, VC-backed projects have an unfair advantage. We can actually check the data on this. And what we see is that VC-backed projects are a relatively small number of the projects that have received retrofunding. And historically, they have not performed as well as projects that do not have any VC funding. So at least to date, VC projects do not seem to have any unfair advantage, even though there are some large ones that have participated in the rounds. And myth number five is that Optimism's badge holders are super good at deciding how much retrofunding each project deserves. The reality is that we are just humans. We have other jobs in many cases, other ecosystems that we are working on. And so it is very difficult for any one badge holder to have a God view of all of the projects and what they're doing and to be able to review each one with a level of care that that project most likely deserves. So I think that a lot of improving retrofunding is going to be about finding the right balance of figuring out what humans and algorithms are good at so that we can make it more efficient, but at the same time ensure that we are learning continuously how to improve the allocations and make sure we get closer to impact. So far, so good. Now we're going to get into the so what. Has this program actually delivered on these promises? Is it effective at rewarding impact? Or is it just an expensive, well-branded marketing campaign? To date, Optimism has supported a lot of projects, more than 700. And there is a power law distribution in terms of how much funding they have received. So what this graph is showing on the x-axis is all of the projects ranked by how much funding they have received since the start of retrofunding. And you can see that an average project that's been in the program has gotten about 40,000 OP, a top one about 160, and there's a few that have received over 500,000, at the time probably worth more than a million dollars. So this has been the distribution so far. It is a power law. It's not a kind of flat, even distribution. And what you can see is that the projects that tend to receive more funding are projects that many of you may be familiar with. At the very top you have Protocol Guild. You also have teams that have focused on developing specifically for Optimism, like Test and Prod. You have core primitives on the super chain, like Account Abstraction, 4337, EAS. You also have some of the major DeFi protocols, like Velodrome, and social apps like Zora. You also have developer libraries, like Ethers and WebM and OpenZeppelin contracts that historically have not received any funding of this scale. And so this is also creating a recurring revenue model for those types of projects. In any case, it isn't just funding a narrow set of DeFi protocols. This is a pretty expansive and diverse set of projects that have been receiving retrofunding. And anecdotally, retrofunding has had a fair amount of impact. One project, L2Beat, they wrote this beautiful letter at the end of one of the rounds thanking retrofunding and the badge holders, but also explaining how it actually changed how they thought about their purpose in the ecosystem. We can Ethereum news. This is also one that I can really relate with, that it was kind of a game changer for them receiving retrofunding. It allowed them to work on this and not pursue other things. At Open Source Observer, this was definitely a game changer for us and gave us the confidence to leave, start a new organization, and focus on building for Optimism. So are we a few outliers or is there some meaningful signal here? At Open Source Observer, the project that I'm working on, we track cohorts of other projects and collections to see how they perform over time. And one of the things that we can clearly see in the data, if you remember that developer capital report I showed at the beginning, the trend line for optimism projects, especially ones that have received retrofunding, is different. On the x-axis here you have time, we have a few milestones related to retrofunding three, the biggest round, and you can see on the y-axis the number of monthly active developers that have been participating in the program, both before and then coming out the other side. And, you know, the line is up and to the right. But there could be a lot of things that are explaining this. So the next thing we want to look at is how would they have compared relative to some kind of a counterfactual or control group. We're not in a position to basically separate out the groups and do a pure experimental test. But what we can do is create a synthetic control using data about other ecosystems. At Open Source Observer, we look at not just optimism, but a range of other crypto ecosystems. So we can create comparable metrics for how projects in those ecosystems have performed in the absence of receiving retrofunding. And so through this, we can see that there is actually a significant increase relative to this synthetic control for projects that received retrofunding from round three. We can do this for any number of metrics, and I've only shown a few here, but this is a comparison of on-chain activity for projects that receive funding from retro funding for around the focus specifically on on-chain builders and here you can see that there is a pretty significant difference that has happened both around the time of sign up but then after the results for retrofunding 4 were announced. The challenge here is that there are other confounding factors. We had the blobs, excuse me, we had the DEN couldn't upgrade, and as a result of that, transaction activity spiked across the board. So we can strip that out. And in this case, we don't see as clear a signal as we saw previously with the developer activity. So this is a whole line of research that we need to do, that we need to get better at to isolate the impact that retrofunding has had on different cohorts of projects. Now if we step back and look at the overall allocation that Optimism has had so far, we can see that most of the funding has actually gone towards these two big boxes over here. So that includes a range of governance, education, education analytics projects, as well as technical contributions to the OP stack. Those are these two big boxes over here. And then off to the right, we have some of the categories that are probably most critical to the success of the super chain, which have historically received relatively less funding. So that's about $14 million for the on-chain builders, and then about $4 million for the developer libraries. So I know there's other programs that are, other rounds that are in the works right now to put more funding into developer tooling. But historically, more of the funding has actually gone in these other areas. And so that could partially explain why there's been less impact on the on-chain activity than general open-source developer activity. So what's next? This is just one of a number of areas that we are excited to explore together with the optimism community. Obviously, there is some quantitative and qualitative evidence that retrofunding is having an impact, but we really aren't in a position right now to make any causal statements about that impact. For us at Open Source Observer, this is a really big area of focus in 2025. We also know, and you don't need to bring up Goodhart's Law just yet, but we know that it's very easy to turn metrics into targets and to game them. On the other hand, we also know that to scale this program, data is going to play a critical role. And so the real challenge here is finding the right balance of human judgment and data that can improve decision making. Metrics should be evolutionary. As you learn more information, they should improve. And we should be able to backtest the results that we get from each of these rounds against the metrics and the decisions that were used to fund those things, and ideally incrementally improve each time around. This is also a big area of focus for Open Source Observer in 2025. One of the things that we learned from recent rounds is that technical experts evaluate impact differently than non-experts. Now, this shouldn't be a surprise to anyone. Up to now, the badge holder pool that Optimism has assembled consists mostly of a mix of experts, technical experts and non-experts. And in round five, there was an experiment that was done to actually test the groups of experts and non-experts prefer different projects. Did they vote differently? The answer, probably not surprisingly, was yes. There were pretty big differences in how they voted, and not just on the projects they picked, but also how much funding they thought top projects should receive. So this chart here shows some of the most divisive projects, ones that received a pretty big difference or big spread between what experts thought they deserved and what non-experts thought they deserved. And so going forward, I think that feedback is going to be used to improve the design of future rounds, and particularly ones that are more technically focused, ensure that the right composition of badge holders are equipped to, you know, vote on what this product should receive. Another issue that comes up are just, like, the incentives this sends to different types of builders. So you have some big projects, you have some small projects, and when you have an allocation which is not like a very steep power law distribution, what you can see is that smaller projects, there might be an incentive to create smaller projects or to atomize your work into kind of a set of very small individual contributions as opposed to capture the collective impact of a larger team we can see this at least in round five where some of the products that did the best had the smallest team on a per contributor basis and so this could create some kind of perverse incentive for teams to fractionalize their work as opposed to representing it as one cohesive team. Trent from Protocol Guild wrote a very nice essay pointing out this fact and doing some comparisons. And then the fifth one is that there is a trade-off between mathematical accuracy and just the vibes and the spirit that comes with each of these rounds. We quants, we tend to suck the life out of things, and there's something very special about the spirit and the vibes that are created around each of these retrofunding rounds. And so as the program becomes more accurate and predictive, there could be a tradeoff in terms of the energy and the attention that this gains because there's less speculation and less hope for some builders. We definitely saw that round three kind of marked a high water point in terms of the social media attention, at least, that retrofunding received. We believe that the upside to figuring out these things and working on these challenges has the potential to be huge. If you just look at the size of the number of developers that are contributing to open source, it's a global movement, and if this were a nation, it would be as large as the population of Thailand or Mexico or Germany. So there is a large, global, borderless movement around open source. And historically, we have not been very good at funding it. If this were a nation, the amount of funding that it is allocating towards its public infrastructure would be on par with Fiji and Swaziland, pretty low down the ranking. So we need to do better. We at Open Source Observer are very excited to work on this problem. We're hoping to attract more data scientists to care about the intersection of public goods and impact and data science. And if that speaks to you, we'd love to hear from you. You can scan the QR code to get in touch, join our Discord. And for any builders that are in the room, Optimism is having a seventh round of retrofunding. It'll be starting hopefully before the end of the year. You can go to retrofunding.optimism.io, get all the details there, and sign up. Thank you very much. Awesome, Carl. So you know next retrofunding, it's coming close. So take the opportunity. Questions that you have for Carl. Let's start that way. Meanwhile please use the QR code to place your questions uh to ease. So go ahead. Hi Carl. Thomas here. Hey. Hi. Uh thanks for the presentation. I'm uh just want to say first of all I'm a huge advocate for open source software. I use it all the time. My day to day activities always always using libraries, frameworks, which you don't even know how open source they are, right? So I wanted to go back on two slides that you had previously mentioned. One of them was around the development on-chain activity. You don't have to go back, but it's fine. I was wondering would you, I know you said there were a handful of other metrics while you were speaking but you outlined these two wondering, would you say these are the most important metrics for measuring and evaluating the impact of funded projects? No I would say that they are good trailing metrics so ideally if you have if you're doing other things well then you'll get more developers you will get more transactions, you'll get more users but you probably don't want to fund these things directly. If you were to just fund people based on the size of their team, then you'd get very big, bloated teams, you wouldn't actually get the impact that you care about. On the other hand, they do probably correlate, in many cases, with, at a high level, the growth of an ecosystem. So I'm not in a position to say there's one metric where you should just fund this thing. And I think that's the whole point, is that we need to test these things out in the wild. We need to combine them in different ways. And then I think over time, we'll see some kind of composite set of metrics, some which are really good as these trailing indicators and some which could actually be more predictive of future success. Yeah, it's a big search space. And just a follow-up question, how much time would you reckon you would need for that? For which part? You mentioned you're gathering data to make a well-informed decision. How much time do you need to make that decision? We see this much more as a challenge for the community. So we can definitely come up with metrics ourselves, but increasingly we want to partner with data teams, you know, projects themselves, people that have an intuition about what metrics they think are most useful, and test those out, experiment with them, and, you know, everything, all the metrics that we're building are fully open, so people can come and test them out directly. Thank you. Yeah. Now we have some questions here. One is, what are the opportunities for data scientists to get involved? Yeah, so scan the QR code. We have a number of contribution opportunities. Some are pretty basic, just like helping add, update, process data. What we're really looking for help is people that have the ability to do modeling. So strong Python skills, they're able to do things like the causal analysis that we showed. They're able to process, help us connect new data sets and process larger and larger amounts of data. Anyone who has the ability to formulate research questions and then design a study around that would be super welcome. But also people that just want to create front ends and dashboards on top of it. There's a lot of cool things you can do. Great. Awesome. And for how long is Optimism going to be running retro PGA fronts? I think the answer is probably forever. That would be the goal. Certainly, the plan is that once the initial treasury runs out, that there's a continuous source of funding that will come in from sequencer fees or from other sources of on-chain revenue. I think the goal, eventually, is that everything that is happening in optimism gets funded by retrofunding. Whether that takes five years or 10 years remains to be seen. But the goal is that this is a system that runs forever. Awesome, Carl. Appreciate it. And appreciate all the questions you have. We just run out of time. So please give a great applause to Carl. Thank you, everyone. And Optimism.",
"eventId": "devcon-7",
- "slot_start": 1731380400000,
- "slot_end": 1731381300000,
- "slot_roomId": "main-stage",
- "sources_youtubeId": "dMLeSMcBskU",
- "sources_swarmHash": "b4b199e383bcf161d7da28671901d39434e7456159cd822eaf6ccf1d802635ab",
- "resources_presentation": "https://docs.google.com/presentation/d/1VG1PST0liQiPWvaWsw3TB7LQkH7HEEXqam66Ds4rCHw"
+ "slot_start": 1731407400000,
+ "slot_end": 1731409200000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/13Pt_GSxCedQkGTiptcOxzfpSOiZRApdYLaDdfjTzw8A",
+ "resources_slides": null,
+ "speakers": [
+ "carl-cervone"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
0,
0,
0,
@@ -556065,6 +554892,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -556227,7 +555055,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -556555,6 +555382,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -556836,6 +555664,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -556899,6 +555728,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -557066,6 +555896,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -557359,9 +556191,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
2,
@@ -557376,31 +556208,43 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "opening-circle",
- "sourceId": "T7THRV",
- "title": "Opening Circle",
- "description": "By master Zoe\r\n(Opening Session)\r\n- Nervous system check-in (to communicate safety and help people settle into the space)\r\n- Short check-in: guided meditation, breathwork, and gentle stretches (approx. 5 minutes) to bring everyone into the present moment\r\n- Intention setting for the conference, guiding participants to align their energy and time with their vision\r\n- Sharing intentions in small groups (3-5 people) to build community connection\r\n- Closing with a gratitude practice\r\n\r\n12 Nov 14:00 - 14:45",
- "track": "Entertainment",
- "type": "Mixed Formats",
- "expertise": "Beginner",
- "audience": "Hobby",
+ "id": "optimize-zkevm-throughput-series-ii",
+ "sourceId": "HRDW3R",
+ "title": "Optimize zkEVM throughput: Series II",
+ "description": "There are different ways to optimize the zkEVM, the one exposed in this workshop is through optimizing the zkASM (zk assembly) code itself so that it consumes fewer counters for the same execution.\r\nThe first 40min of the workshop is a deep explanation of the zkASM language, instructions, operations, counters, build... And the rest of the time we will be live coding and explaining in detail two optimized core functions of the zkEVM so that attendees can appreciate the before and after optimizing",
+ "track": "Layer 2",
+ "type": "Workshop",
+ "expertise": "Expert",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "L2"
+ ],
+ "tags": [
+ "ZK-EVMs",
+ "EVM-equivalent",
+ "ZKP",
+ "l2",
+ "EVM-equivalent",
+ "ZK-EVMs",
+ "ZKP"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "ignasi-ramos",
+ "carlos-matallana"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731394800000,
- "slot_end": 1731397500000,
- "slot_roomId": "decompression-room",
- "resources_presentation": "https://docs.google.com/presentation/d/1n226DY0rUYiKnECT9xm9IZ_yu2qSeuhOfgg63eVqUM0"
+ "slot_start": 1731571200000,
+ "slot_end": 1731576600000,
+ "slot_roomId": "classroom-c",
+ "resources_presentation": "https://docs.google.com/presentation/d/1j-dXA_XZk45fwe4mOSLfaBUXA0DVQTMQ1GLhESBsAZM"
},
"vector": [
0,
@@ -557410,8 +556254,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -557907,6 +556749,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -558227,6 +557071,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -558474,6 +557319,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -558497,6 +557343,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -558581,6 +557428,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -558703,22 +557552,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
0,
0,
0,
@@ -558730,6 +557563,14 @@
2,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -558738,63 +557579,47 @@
},
{
"session": {
- "id": "opsec-for-the-dark-forest-or-how-to-avoid-getting-rekt",
- "sourceId": "TAEPPF",
- "title": "OpSec for the Dark Forest (or how to avoid getting rekt)",
- "description": "We will focus on the most important things you need to do to have a good OpSec to survive in the Crypto Dark Forest. I will cover: computer, mobile phone, email, telegram, social media, phone numbers, password managers and 2FA strategy, security software & social engineering.\r\nThis is based on many years of experience and in the cases we see daily on SEAL 911.",
- "track": "Security",
+ "id": "optimizing-full-node-costs-with-monitor-tools",
+ "sourceId": "D9UAVG",
+ "title": "Optimizing full node costs with monitor tools",
+ "description": "Running a full node is a fundamental component of participating in a decentralized network. However, the operational cost associated with running a full node can be prohibitively high, even for an archive node, it needs a lot of CPU/Memory and SSD disks. At our organization, we have successfully implemented a cost reduction strategy by using the pprof tool, along with grafana and prometheus in our node infrastructure.",
+ "track": "Core Protocol",
"type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Privacy",
- "Security",
- "Hacks",
- "2FA",
- "dprk",
- "2FA",
- "Hacks",
- "Privacy",
- "Security"
- ],
"keywords": [
- "OpSec",
- "Social Engineering",
- "Malware",
- "0days",
- "DPRK"
+ "performance optimization",
+ "service level improvement"
+ ],
+ "tags": [
+ "Architecture",
+ "Developer Infrastructure",
+ "Best Practices",
+ "service",
+ "level",
+ "improvement",
+ "Architecture",
+ "Best Practices",
+ "Developer Infrastructure"
],
- "duration": 542,
"language": "en",
- "sources_swarmHash": "0fb90958816f38c563510ad9f68ada525a114c7dbdf95c1534f4a4675a6e902c",
- "sources_youtubeId": "nM2BBNlIRe4",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67332a0d3a168eb535728b37.vtt",
- "transcript_text": " Leonardo Silva Reviewer's Reviewer's Name How are you guys? How's everything? Well, today I had a workshop, but they told me, okay, you don't have an hour, you have five minutes. So I'll make it brief, and I'll go to the conclusions. Well, I'm Pablo Sabatera. I do web-free operational security at OPSEC, where we train and audit companies for everything that is not in a smart contract. And I am a contributor of SIL 911, where we do incident response for blockchain. So what are we going to talk about today? Simple things that we can do to enhance our OPSEC, right? So one thing that is very important to know is that it's not so important if I use Windows or Mac, Android or iPhone, Chrome or Safari or whatever. The important thing is how we configure the tools that we use, right? So first thing I want to talk about very fast, two-factor authentication, things that you do not have to do, do it with SMS. And we cannot do it anymore with TOTP apps like Google Authenticator or Authy. Those kind of 2FAs can be phased and they're being phased every day. We need to use YubiKeys, right? But not the YubiKey with the normal OTP mode. YubiKey with FIDO2. That cannot be phished. This is happening a lot in the ecosystem. Next, soldier engineering. We have to be very, very, very careful for this. Like professionals hack people, not systems, right? Today is much cheaper to attack someone and much easier than to attack a system. So be very careful with supposed recruiters, VC fans, investors and journalists that want to invite you to some call or something. Never download anything. Be very careful with PDFs that you open. They are usually infected. And if someone looks, if something looks like strange, it's probably a scam, right? And everything is a scam until proven otherwise, everything. Next, eventually all of us will get hacked. That will happen. It's not a matter of it will happen or not, it's just a matter of time. So we need to be able to contain the damage so that you know when someone in your team has been hacked, the damage will be contained. Even the founders, even the CISO, even the CTO, everyone. Use an antivirus and a firewall. People think that, no, I use a Mac, I don't need an antivirus. Use an antivirus. MacBook is not good with virus alone. There is a good foundation called Objective-C that has many tools for security in Mac. One more thing, the attack will come from a trusted source, right? For example, we saw how they were hacking the Eventbrite of the events at Delcon one hour before the event, and they send a message from the real account to everyone, hey, you have to mint this NFT. You mint it, your wallet is drained completely. You receive an email that says that it's from Trezor, and it's really from Trezor, from their official system, but it has been hacked. They send you a drainer. You are done. One more thing. Use a password manager and never, never, ever reuse a password, right? But let's use password managers, and we have to have them configured very securely but never ever ever and this is very important very important never put a seed phrase in a password manager right for sure many of you have done it yeah and you say oh I did it but it's okay my password by my password manager is secure no it's not if you have ever put a seed phrase in a password manager you cannot use that wallet anymore you have ever put a seed phrase in a password manager, you cannot use that wallet anymore. You have to move to a new one. Use hardware wallets. Hardware wallets are important. Many will think, okay, these things that this guy are telling us are very basic. This basic stuff is the reason why today 85% of lost funds are lost every day, right? In blockchain. It's not anymore due to smart contracts. We have gotten very, very good at security with smart contracts. And money is being stolen like this. So you have to be really, really careful. Well, I hope you liked it. I will be here if you want to talk more about this. This was a very, very, very small resume. But operational security is important. It's the number one reason how we are being attacked by very sophisticated threat actors. Something that is happening is that in the industry, we have one of the worst objects in all the industries worldwide because we don't have regulations so any company does whatever they think that it's okay and it's not. And on the other side we have very very sophisticated threat actors from nation states that are doing this kind of attacks and they know what they're doing so be extra extra careful I hope you liked it thank you Pablo any questions for Pablo yep oh there do you want to give a go this is on your side and do you want to give it a go? Because it's on your side. Do you want to throw? I have to throw it there? You're much better than me. So what would you recommend to people to store their seed phrases securely? Because I think the challenge is, I mean, I'm a CTO as well, you either have to make it secure or you want to prevent people writing it down on a post-it note. I think that writing down seed phrases is one of the best ways to store them. One hack that you can use that is very, very simple, was told to me by one of the guys from the Red Guild, is buying anti-chambering bags, the ones that you commerce use. So you write it there, and wherever it is that you save it, you save it with that. So with that, you are sure that it has never been seen by anyone. If sometime it was seen by someone, they have to break that. So that's another very good way, and I really like Shamir, like having your seed phrase and cutting it in places in three lists, but only you need two of those three lists, that gives you confidentiality and availability. So I think that's pretty good. Thank you. Do we see any other questions? Oh, over there. There was one question. Yeah. All right. I actually wrote down my question. How do you choose a product for secrets like SSH keys, OAuth tokens, et cetera, management across multiple cloud providers? So a product for what? Sorry? A product for secrets management like SSH keys of tokens across multiple cloud providers I don't have a good answer for that. So I'm not I'm not sure what would I use? The guys that are really because I only talk about stuff I am really really good at right and the guys from the Red Guild have a very good guide on that, so they will be maybe able to ask a question from Fargo rather than me. No, thank you. Thank you. What do you think? What is the most secure, multi-sig wallet or hardware wallet? No, I think that safe is good. And regarding hardware wallets, I consider that all of them are also very good, Tresor, Ledger, SafePal. I think it's how you use them, right? But I think that all of them are very good, and I think that safe is also very, very good. Yeah, there's a question over there. You covered a lot of stuff there, but is there any advice you give on browsers or how you deal with browsers? And that's generally where a lot of stealers are sitting. Yeah, browsers, be very, very careful with the extensions you download. Like, we browsers, be very, very careful with the extensions you download. Like, we have to be very, very careful with extensions. There are lots of malicious extensions. And the other good practice is to have more than one session. For example, you use Chrome, you have five sessions, one for work, one for DeFi, one for personal stuff, one for this, one for that, for that. And you also can have another browser, right? Or even better than that is having another session in a VPN, right? So you have it, sorry, in a virtual machine. So you have another virtual machine with another browser if you want to keep it really separate, and that's also pretty good. Okay, thank you very much.",
- "eventId": "devcon-7",
- "slot_start": 1731405600000,
- "slot_end": 1731406200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1jLrqWU4lm17NODOESY5ysFcreo3AXNtlq_mO-78OMZY",
- "resources_slides": null,
"speakers": [
- "pablo-sabbatella"
- ]
+ "jsvisa"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731571800000,
+ "slot_end": 1731572400000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1DOTMyJmIPI5tdLiG_5PoOmjA44ieroq22BSvZjFN9no"
},
"vector": [
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -559216,6 +558041,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -559291,7 +558117,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -559538,7 +558363,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -559571,6 +558395,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -559593,6 +558418,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -559600,6 +558426,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -559654,7 +558481,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -559705,7 +558531,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -559789,7 +558614,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -559827,6 +558651,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -559973,6 +558798,7 @@
0,
0,
2,
+ 2,
0,
0,
0,
@@ -560121,52 +558947,39 @@
},
{
"session": {
- "id": "optimism-retro-funding-so-far-so-good-so-what",
- "sourceId": "QCMZS8",
- "title": "Optimism Retro Funding: So Far, So Good, So What!?",
- "description": "So far, over 50M OP has been awarded to projects with no strings attached. So good, another 800M OP is planned for future rounds. So what ... is the impact? My talk will offer an objective, data-driven perspective on the \"so what\" of Optimism's Retro Funding. It will include analysis on how different cohorts of projects have performed longitudinally across a variety of growth and quality metrics, while controlling for different funding and market-related effects.",
- "track": "Coordination",
+ "id": "oracles-for-number-values",
+ "sourceId": "DBKAJX",
+ "title": "Oracles for number values",
+ "description": "We will overview the history and state of research on how to design a cryptoeconomic oracle that outputs a number value. One wants such tools for price oracles, but also for bringing other information on-chain, e.g. the damages to award from an on-chain insurance contract. We will look at approaches ranging from Vitalik's 2014 SchellingCoin proposal to ideas drawing from social choice theory, including based on recent research. We will explore tradeoffs including resistance to several attacks.",
+ "track": "Cryptoeconomics",
"type": "Talk",
"expertise": "Intermediate",
"audience": "Research",
"featured": false,
"doNotRecord": false,
- "tags": [
- "RPGF",
- "Collective Intelligence",
- "Open Source Software",
- "grants",
- "Collective Intelligence",
- "Open Source Software",
- "RPGF"
- ],
"keywords": [
- "Data Science",
- "Impact Measurement",
- "Grants"
+ "Oracles"
+ ],
+ "tags": [
+ "Mechanism design",
+ "oracle",
+ "Mechanism",
+ "design"
],
- "duration": 1542,
"language": "en",
- "sources_swarmHash": "047944c236f3e1dd0245dbd16955b54f0bc3a72e7dfec5f04b2ab12b56574f74",
- "sources_youtubeId": "MmjAhdEbnV0",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673358ad3a168eb535865df1.vtt",
- "transcript_text": " Thanks everyone. Before getting into crypto, I did work in the coffee supply chain and I've been getting a lot of questions about where the best coffee is in Bangkok and I'm still looking for an answer. So if anybody knows where to go for some excellent specialty coffee, please hit me up. I'd love to check that out. Today I'm going to be talking about Optimism Retrofunding. It's a experimental grants program being run by the Optimism Collective. And as a data enthusiast, it creates this incredible substrate for looking at the effectiveness of different grant programs. I'm the co-founder of an organization called Open Source Observer. We're building a free analytics platform and a community of data scientists who care about measuring impact in the open. And so today we're going to be talking about the impact that Optimism is achieving and identifying some opportunities to improve and double down on where that impact has been most effective. So I guess just a quick check. How many of the people in this room are familiar with retrofunding optimism? All right, pretty good. So I have a few slides that will be a bit of a cursory introduction to optimism. I think the main point that I want to get across here is that I believe this is a really important experiment for the world to pay attention to and to understand. Regardless of whether it succeeds or fails, in the long run, there's something special and different that is happening here, and it's worth paying attention to. So another chart, or first chart of the day. We have a lot of charts coming. But it has another poll. How many of you have seen this before? How many of you are familiar with the Electric Capital Developer Report? Have you seen this? All right. Not as much awareness. This is one of the most looked at reports that the crypto industry puts out. And they track a metric called monthly active developers. They've been putting this out for quite some time now. It's basically an indicator of how many developers there are working across all of crypto, not just Ethereum. Every ecosystem is captured here. And so what you can see from this chart is that things went up a lot in 2021. They kind of plateaued in 2022. And now things have gone down in aggregate from a peak of around 30,000 to about 26,000 monthly active developers by this metric. To put this in comparison, I recently heard that Gemini, which is Google's AI platform, they have 1.5 million active developers by their count. I don't know if they're comparable, but orders of magnitude greater than what we have here across the crypto industry. Here's another metric. This one is the amount of venture capital that has gone into crypto since the beginning, basically. This chart stops at 2022, but there's another number that they care about, which is the total amount of deal flow. If we add this up, we get a number of around $80 billion has gone into the space since 2016. So I think the interesting thing is actually when you start combining these types of data sets. I don't have the ability to go in and look exactly how they calculate these things, but I can overlay the two. And when I do that, I can come up with a new metric of my own. And that metric is the dollars spent per developer retained. And what you can see here is that for every $3.1 million that has been invested prospectively as risk capital, we only have one retained developer in the industry still here to show for that. So I think we can do better, and we hope to do better. The point is not just that the venture capital can improve, but really that prospective funding is difficult. Behind every one of these deals, there's a team of professionals that are researching these companies and making bets. And the reality is that it's often quite difficult to do this. And there's an acceptance that most of these bets are not going to work out. So prospective funding is hard. Retrofunding is based on the principle that it is easier to identify something that has worked looking back than to predict it going forward. Vitalik helped design the mechanism. Optimism has been rolling it out. And it's a pretty unique way of creating markets around impact. Now to be clear I don't think the most die-in-the-wool retrofunding maxi would say that retrofunding is the only way that anything in the world should be funded but the important point here is that right now we have a surplus of, not a surplus, but a large amount of prospective funding and we need more retrospective funding in the world to signal what things we value and drive more people to build in those directions. And so that's what we'll be talking about today. At launch, Optimism allocated 850 million tokens from its treasury to retrofunding. This is a big deal. And they made a promise that if you create impact on the Optimism collective, you will be rewarded for that impact. What that impact is, how it will be rewarded, TBD, but that's what we're here to discuss. To date, optimism has deployed around 60 million OP, or at least allocated, not all that has gone out the door, which is a pretty small share of its treasury. So even though this is a large sum of tokens, we're still very much in the early innings. And each round has been designed around a specific set of experiments, hypotheses that they wanted to test. Round one, I think, was completely off chain. It was a proof of concept, about 50 projects, no applications. The selection was done, I think, by the OP Labs team. Rounds two and three are where this program gained a lot of recognition. They were big mega rounds. 40 million OP went out in total. More than 600 projects participated. There were 100 badge holders, also known as citizens, who were voting on projects. I was a badge holder. I think there are a few in the room still. But they were given this enormous task of reviewing all of these projects and identifying which ones they thought should deserve a certain amount of funding. In response to the mega rounds in 2024, this past year, optimism changed the scope a little bit and instead of having these large mega rounds, they moved to a system where you have smaller, more tightly scoped rounds with tighter eligibility criteria. And in those rounds, they also tested different experiments around badge holders and guest voters and expertise. In total, about 18 million has gone out, and there's more allocated through the end of 2024. Again, we're going to be looking at the results of the program so far, but putting this in the scale of other public goods funding experiments, this is pretty unique. It's pretty large. And my team and I at Open Source Observer, the fact that this was a real experiment of significant scale was what attracted us to want to pay attention and work at Optimism. There's a lot of economists that like writing long papers about how public goods funding is broken, but here was a real chance to throw magic internet money and test whether we could actually change the incentive landscape. So I think people should pay attention to this, regardless of whether they participate directly or not. But first, because the only thing that people like more than throwing tokens around is complaining about things on Twitter, I want to address a few myths about optimism and the program of retrofunding. So the first myth is that retrofunding comes with conditions. The reality is the projects that receive retrofunding are getting with no strings attached. They can cash out, they can migrate their projects to Solana, they can delegate to governance, or they can keep building. And what we see continuously is that most people actually tend to keep building on optimism. The second myth is that retrofunding is optimism's only grant program. This is also not true. It is also... Oops, sorry. It is not the only grants program. It's also not the largest grants program. Optimism also runs perspective funding. Since 2024, they've given out more than 60 million, I believe, in perspective mission-based grants. And most of the projects that are receiving retrofunding have also received some form, or a large number of the products that have received retrofunding have also participated in these prospective grants. I think there's a narrative that Optimism expects all of its teams to work for free and pray for retrofunding. This is not the case. There are various mechanisms and retrofunding is just one of them, and obviously the most experimental at this point. Myth number three, Optimism no longer cares about public goods. You've probably heard this before if you follow the optimism narrative on Twitter. I think this narrative really took root after optimism changed the name of the program, but the reality is that there was never a formal definition of what a public good is. Optimism and I kind of agree with this definition have always viewed it as a kind of a spectrum and the role of retrofunding is to fill the gap. It's identify where is the market not effective in rewarding impact and using tokens strategically to fill that gap. Myth number four, VC-backed projects have an unfair advantage. We can actually check the data on this. And what we see is that VC-backed projects are a relatively small number of the projects that have received retrofunding. And historically, they have not performed as well as projects that do not have any VC funding. So at least to date, VC projects do not seem to have any unfair advantage, even though there are some large ones that have participated in the rounds. And myth number five is that Optimism's badge holders are super good at deciding how much retrofunding each project deserves. The reality is that we are just humans. We have other jobs in many cases, other ecosystems that we are working on. And so it is very difficult for any one badge holder to have a God view of all of the projects and what they're doing and to be able to review each one with a level of care that that project most likely deserves. So I think that a lot of improving retrofunding is going to be about finding the right balance of figuring out what humans and algorithms are good at so that we can make it more efficient, but at the same time ensure that we are learning continuously how to improve the allocations and make sure we get closer to impact. So far, so good. Now we're going to get into the so what. Has this program actually delivered on these promises? Is it effective at rewarding impact? Or is it just an expensive, well-branded marketing campaign? To date, Optimism has supported a lot of projects, more than 700. And there is a power law distribution in terms of how much funding they have received. So what this graph is showing on the x-axis is all of the projects ranked by how much funding they have received since the start of retrofunding. And you can see that an average project that's been in the program has gotten about 40,000 OP, a top one about 160, and there's a few that have received over 500,000, at the time probably worth more than a million dollars. So this has been the distribution so far. It is a power law. It's not a kind of flat, even distribution. And what you can see is that the projects that tend to receive more funding are projects that many of you may be familiar with. At the very top you have Protocol Guild. You also have teams that have focused on developing specifically for Optimism, like Test and Prod. You have core primitives on the super chain, like Account Abstraction, 4337, EAS. You also have some of the major DeFi protocols, like Velodrome, and social apps like Zora. You also have developer libraries, like Ethers and WebM and OpenZeppelin contracts that historically have not received any funding of this scale. And so this is also creating a recurring revenue model for those types of projects. In any case, it isn't just funding a narrow set of DeFi protocols. This is a pretty expansive and diverse set of projects that have been receiving retrofunding. And anecdotally, retrofunding has had a fair amount of impact. One project, L2Beat, they wrote this beautiful letter at the end of one of the rounds thanking retrofunding and the badge holders, but also explaining how it actually changed how they thought about their purpose in the ecosystem. We can Ethereum news. This is also one that I can really relate with, that it was kind of a game changer for them receiving retrofunding. It allowed them to work on this and not pursue other things. At Open Source Observer, this was definitely a game changer for us and gave us the confidence to leave, start a new organization, and focus on building for Optimism. So are we a few outliers or is there some meaningful signal here? At Open Source Observer, the project that I'm working on, we track cohorts of other projects and collections to see how they perform over time. And one of the things that we can clearly see in the data, if you remember that developer capital report I showed at the beginning, the trend line for optimism projects, especially ones that have received retrofunding, is different. On the x-axis here you have time, we have a few milestones related to retrofunding three, the biggest round, and you can see on the y-axis the number of monthly active developers that have been participating in the program, both before and then coming out the other side. And, you know, the line is up and to the right. But there could be a lot of things that are explaining this. So the next thing we want to look at is how would they have compared relative to some kind of a counterfactual or control group. We're not in a position to basically separate out the groups and do a pure experimental test. But what we can do is create a synthetic control using data about other ecosystems. At Open Source Observer, we look at not just optimism, but a range of other crypto ecosystems. So we can create comparable metrics for how projects in those ecosystems have performed in the absence of receiving retrofunding. And so through this, we can see that there is actually a significant increase relative to this synthetic control for projects that received retrofunding from round three. We can do this for any number of metrics, and I've only shown a few here, but this is a comparison of on-chain activity for projects that receive funding from retro funding for around the focus specifically on on-chain builders and here you can see that there is a pretty significant difference that has happened both around the time of sign up but then after the results for retrofunding 4 were announced. The challenge here is that there are other confounding factors. We had the blobs, excuse me, we had the DEN couldn't upgrade, and as a result of that, transaction activity spiked across the board. So we can strip that out. And in this case, we don't see as clear a signal as we saw previously with the developer activity. So this is a whole line of research that we need to do, that we need to get better at to isolate the impact that retrofunding has had on different cohorts of projects. Now if we step back and look at the overall allocation that Optimism has had so far, we can see that most of the funding has actually gone towards these two big boxes over here. So that includes a range of governance, education, education analytics projects, as well as technical contributions to the OP stack. Those are these two big boxes over here. And then off to the right, we have some of the categories that are probably most critical to the success of the super chain, which have historically received relatively less funding. So that's about $14 million for the on-chain builders, and then about $4 million for the developer libraries. So I know there's other programs that are, other rounds that are in the works right now to put more funding into developer tooling. But historically, more of the funding has actually gone in these other areas. And so that could partially explain why there's been less impact on the on-chain activity than general open-source developer activity. So what's next? This is just one of a number of areas that we are excited to explore together with the optimism community. Obviously, there is some quantitative and qualitative evidence that retrofunding is having an impact, but we really aren't in a position right now to make any causal statements about that impact. For us at Open Source Observer, this is a really big area of focus in 2025. We also know, and you don't need to bring up Goodhart's Law just yet, but we know that it's very easy to turn metrics into targets and to game them. On the other hand, we also know that to scale this program, data is going to play a critical role. And so the real challenge here is finding the right balance of human judgment and data that can improve decision making. Metrics should be evolutionary. As you learn more information, they should improve. And we should be able to backtest the results that we get from each of these rounds against the metrics and the decisions that were used to fund those things, and ideally incrementally improve each time around. This is also a big area of focus for Open Source Observer in 2025. One of the things that we learned from recent rounds is that technical experts evaluate impact differently than non-experts. Now, this shouldn't be a surprise to anyone. Up to now, the badge holder pool that Optimism has assembled consists mostly of a mix of experts, technical experts and non-experts. And in round five, there was an experiment that was done to actually test the groups of experts and non-experts prefer different projects. Did they vote differently? The answer, probably not surprisingly, was yes. There were pretty big differences in how they voted, and not just on the projects they picked, but also how much funding they thought top projects should receive. So this chart here shows some of the most divisive projects, ones that received a pretty big difference or big spread between what experts thought they deserved and what non-experts thought they deserved. And so going forward, I think that feedback is going to be used to improve the design of future rounds, and particularly ones that are more technically focused, ensure that the right composition of badge holders are equipped to, you know, vote on what this product should receive. Another issue that comes up are just, like, the incentives this sends to different types of builders. So you have some big projects, you have some small projects, and when you have an allocation which is not like a very steep power law distribution, what you can see is that smaller projects, there might be an incentive to create smaller projects or to atomize your work into kind of a set of very small individual contributions as opposed to capture the collective impact of a larger team we can see this at least in round five where some of the products that did the best had the smallest team on a per contributor basis and so this could create some kind of perverse incentive for teams to fractionalize their work as opposed to representing it as one cohesive team. Trent from Protocol Guild wrote a very nice essay pointing out this fact and doing some comparisons. And then the fifth one is that there is a trade-off between mathematical accuracy and just the vibes and the spirit that comes with each of these rounds. We quants, we tend to suck the life out of things, and there's something very special about the spirit and the vibes that are created around each of these retrofunding rounds. And so as the program becomes more accurate and predictive, there could be a tradeoff in terms of the energy and the attention that this gains because there's less speculation and less hope for some builders. We definitely saw that round three kind of marked a high water point in terms of the social media attention, at least, that retrofunding received. We believe that the upside to figuring out these things and working on these challenges has the potential to be huge. If you just look at the size of the number of developers that are contributing to open source, it's a global movement, and if this were a nation, it would be as large as the population of Thailand or Mexico or Germany. So there is a large, global, borderless movement around open source. And historically, we have not been very good at funding it. If this were a nation, the amount of funding that it is allocating towards its public infrastructure would be on par with Fiji and Swaziland, pretty low down the ranking. So we need to do better. We at Open Source Observer are very excited to work on this problem. We're hoping to attract more data scientists to care about the intersection of public goods and impact and data science. And if that speaks to you, we'd love to hear from you. You can scan the QR code to get in touch, join our Discord. And for any builders that are in the room, Optimism is having a seventh round of retrofunding. It'll be starting hopefully before the end of the year. You can go to retrofunding.optimism.io, get all the details there, and sign up. Thank you very much. Awesome, Carl. So you know next retrofunding, it's coming close. So take the opportunity. Questions that you have for Carl. Let's start that way. Meanwhile please use the QR code to place your questions uh to ease. So go ahead. Hi Carl. Thomas here. Hey. Hi. Uh thanks for the presentation. I'm uh just want to say first of all I'm a huge advocate for open source software. I use it all the time. My day to day activities always always using libraries, frameworks, which you don't even know how open source they are, right? So I wanted to go back on two slides that you had previously mentioned. One of them was around the development on-chain activity. You don't have to go back, but it's fine. I was wondering would you, I know you said there were a handful of other metrics while you were speaking but you outlined these two wondering, would you say these are the most important metrics for measuring and evaluating the impact of funded projects? No I would say that they are good trailing metrics so ideally if you have if you're doing other things well then you'll get more developers you will get more transactions, you'll get more users but you probably don't want to fund these things directly. If you were to just fund people based on the size of their team, then you'd get very big, bloated teams, you wouldn't actually get the impact that you care about. On the other hand, they do probably correlate, in many cases, with, at a high level, the growth of an ecosystem. So I'm not in a position to say there's one metric where you should just fund this thing. And I think that's the whole point, is that we need to test these things out in the wild. We need to combine them in different ways. And then I think over time, we'll see some kind of composite set of metrics, some which are really good as these trailing indicators and some which could actually be more predictive of future success. Yeah, it's a big search space. And just a follow-up question, how much time would you reckon you would need for that? For which part? You mentioned you're gathering data to make a well-informed decision. How much time do you need to make that decision? We see this much more as a challenge for the community. So we can definitely come up with metrics ourselves, but increasingly we want to partner with data teams, you know, projects themselves, people that have an intuition about what metrics they think are most useful, and test those out, experiment with them, and, you know, everything, all the metrics that we're building are fully open, so people can come and test them out directly. Thank you. Yeah. Now we have some questions here. One is, what are the opportunities for data scientists to get involved? Yeah, so scan the QR code. We have a number of contribution opportunities. Some are pretty basic, just like helping add, update, process data. What we're really looking for help is people that have the ability to do modeling. So strong Python skills, they're able to do things like the causal analysis that we showed. They're able to process, help us connect new data sets and process larger and larger amounts of data. Anyone who has the ability to formulate research questions and then design a study around that would be super welcome. But also people that just want to create front ends and dashboards on top of it. There's a lot of cool things you can do. Great. Awesome. And for how long is Optimism going to be running retro PGA fronts? I think the answer is probably forever. That would be the goal. Certainly, the plan is that once the initial treasury runs out, that there's a continuous source of funding that will come in from sequencer fees or from other sources of on-chain revenue. I think the goal, eventually, is that everything that is happening in optimism gets funded by retrofunding. Whether that takes five years or 10 years remains to be seen. But the goal is that this is a system that runs forever. Awesome, Carl. Appreciate it. And appreciate all the questions you have. We just run out of time. So please give a great applause to Carl. Thank you, everyone. And Optimism.",
+ "speakers": [
+ "william-george"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731407400000,
- "slot_end": 1731409200000,
+ "slot_start": 1731659400000,
+ "slot_end": 1731661200000,
"slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/13Pt_GSxCedQkGTiptcOxzfpSOiZRApdYLaDdfjTzw8A",
- "resources_slides": null,
- "speakers": [
- "carl-cervone"
- ]
+ "resources_presentation": "https://docs.google.com/presentation/d/1gnmIdI5LzbPxcbx7iSARUelWaUg1VuvSthLIpccggM8"
},
"vector": [
0,
0,
+ 6,
0,
0,
0,
@@ -560176,9 +558989,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -560923,6 +559733,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -560951,8 +559762,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -561015,7 +559824,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -561184,8 +559992,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -561355,6 +560161,9 @@
0,
0,
0,
+ 2,
+ 2,
+ 2,
0,
0,
0,
@@ -561500,38 +560309,43 @@
},
{
"session": {
- "id": "optimize-zkevm-throughput-series-ii",
- "sourceId": "HRDW3R",
- "title": "Optimize zkEVM throughput: Series II",
- "description": "There are different ways to optimize the zkEVM, the one exposed in this workshop is through optimizing the zkASM (zk assembly) code itself so that it consumes fewer counters for the same execution.\r\nThe first 40min of the workshop is a deep explanation of the zkASM language, instructions, operations, counters, build... And the rest of the time we will be live coding and explaining in detail two optimized core functions of the zkEVM so that attendees can appreciate the before and after optimizing",
- "track": "Layer 2",
- "type": "Workshop",
- "expertise": "Expert",
- "audience": "Developer",
+ "id": "our-cypherpunk-approach-to-self-sovereign-digital-identity-does-not-work-in-real-world",
+ "sourceId": "USJSPF",
+ "title": "Our (Cypherpunk) approach to Self-Sovereign Digital Identity does not work in real world",
+ "description": "For years our community is using cryptography and privacy-enhancing technologies trying to build solutions that will bring people control over their digital identities. How far have we got?\r\n\r\nThis talk would like to expose a gap that exists between our Cypherpunk approach to SSI and what a real world project needs / wants / can do.\r\n\r\nIf we want our SSI solutions to bring control over their digital identities back to people, it seems we need to take a different approach.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "L2"
- ],
"tags": [
- "ZK-EVMs",
- "EVM-equivalent",
- "ZKP",
- "l2",
- "EVM-equivalent",
- "ZK-EVMs",
- "ZKP"
+ "ssi",
+ "Digital Sovereignty",
+ "Identity",
+ "Privacy"
],
- "language": "en",
- "speakers": [
- "ignasi-ramos",
- "carlos-matallana"
+ "keywords": [
+ "ssi"
],
+ "duration": 442,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "7q2YD5QUHmo",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": "67349f549dbb7a90e13a18b4",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67349f549dbb7a90e13a18b4.vtt",
+ "transcript_text": " Hello everyone and thank you for being here. I know the party has already started. I'm looking at you, Carlos. Thanks again for being here. My name is Miros. Thank you for the nice introduction. I work in privado ID. And I want to talk a bit about why I think that our, and I say our because I consider myself to be part of the movement, cypherpunk approach to self-sovereign digital identity does not work. So we have been trying for years, right, to build tools that will protect people and to use all the cryptography and technology that we have, but how far have we actually got? We are offering full user control, privacy, decentralization, anonymity, and business that is actually building applications for people to use. And I'm not talking about us, right, in a battery bubble. I'm talking about people here on the street. Well, these businesses, they want UX, they want integration, they want compliance. What are the key challenges? Well, these, right? First one is the usability. Talk about private keys, but if I look at the initials concept, multi-chain, a lot of words that are un-understandable for a lot of people, right? Ease of integration. If we are talking about people that need to use our technology, or let's say businesses to use our technology, decentralization, most probably not going to work or comes with a lot of hurdles, right? And we need to work with legacy systems if we want billions of people actually to benefit from all this. Compliance, sadly, but we know that the KYC, AML, and other stuff are required, right? Like it or not. So the cypherpunk vision of total privacy and anonymity is an ideal, right? And I'm not saying to kill that, right? We need to keep the ideal there and work toward that, but we need to change some stuff. I call for an incremental approach. I'm just going to take one example here, right, an opportunity, but there are much more of these out there, being the European Digital Identity Incentive. So they recognize the problem, right, that the privacy of the regular people, of the common people, is in danger. And their solution is not ideal, right? They offer selective disclosure, data minimization, verifiable credentials. It's a good step forward, but it's not cypherpunk, right? But I think we should join this. We should hop on the bandwagon, because we can influence things. We can try to change some stuff. And actually, this is why I'm here, right? I would like that this debate happens here between all of us and all of you that are out there on the Internet. So what we could win, right? We could promote privacy for standards. We could encourage more adoption. We can actually have more private and decentralized alternatives. Jordi Bailina yesterday in his talk mentioned, and I agree with that, although it's not ideal, right? I would rather trust my private data with a government than with a corporation. Again, it's not ideal, but it is a step forward, right? And no, this does not mean that we stop fighting, right? I invite you all to think critically about building, advocating, or using, right, the solutions that are both streaming towards cypherpunk, right, but are adaptable and can be used in real world, right? Let's please try to balance, right, idealism with practical constraints. So we can achieve more with what we have today streaming towards the ideal world, right? There were a lot of talks, and I like the talk that was here, the previous from Evian and the other one, right? And yesterday, there were a lot of also talks about cypherpunk movement. It is important. All of you need to join if you are not part of that. But again, I advocate for an approach that is incremental, that we think not only about ourselves, but we think about the people that are out there on the street. That doesn't mean that we do not need Tor, that we do not need all the tools for journalists, for people that are doing really important things. That, yes, but also yes for the common people, right? The struggle continues. I'm Miros. Thank you. Thank you very much. Thank you. So we will have some time to ask a few questions. Raise your hand if you have any questions. I can throw the red square at you. Oh, you want to? No, no, no. I mean, I'm challenging. Oh, okay. Any questions? Do you want to throw it? No, no. I don't want to hurt the CSO of my company. Maros, obviously there are a lot of examples that you've described of ways in which things are suboptimal. Now, ourselves aside, who else is doing it right? government leaders, are there enterprises, are there idealists or leaders who we should look to in our institutional structures as potential partners? I think yes. I mean, whoever was on a bunch of all these talks that happened, and they are going to happen tomorrow and the day after, there are people, right, that are trying to do all this. And, of course, I know our team best, and we are trying the best that we can. But I really like, for example, having the initiative coming from the European Union. That's 650 million people that tomorrow can have privacy towards Amazon. Yes, where do I sign, right? But that's not the end game. So there are people, there are things that we can do and and that's it right no you're right absolutely that's a great call out European Union and also shout out to the etherium foundation for showing up this week on this topic too yes and that's a drop mic, literally. Any more questions? Okay. No? Well, thank you very much. Thank you. Please give a nice round of applause to Milos. Thank you.",
"eventId": "devcon-7",
- "slot_start": 1731571200000,
- "slot_end": 1731576600000,
- "slot_roomId": "classroom-c",
- "resources_presentation": "https://docs.google.com/presentation/d/1j-dXA_XZk45fwe4mOSLfaBUXA0DVQTMQ1GLhESBsAZM"
+ "slot_start": 1731494400000,
+ "slot_end": 1731495000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1tieWVdz2ClCZUAnL4cwbHgtEkk_tNIfgbdodCv6BfoY",
+ "resources_slides": null,
+ "speakers": [
+ "miros"
+ ]
},
"vector": [
0,
@@ -561539,8 +560353,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -562042,7 +560854,6 @@
0,
0,
6,
- 6,
0,
0,
0,
@@ -562335,6 +561146,47 @@
0,
0,
0,
+ 2,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -562610,7 +561462,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -562634,7 +561485,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -562685,43 +561535,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
+ 2,
0,
0,
0,
@@ -562846,11 +561660,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
2,
@@ -562861,54 +561675,50 @@
0,
0,
0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "optimizing-full-node-costs-with-monitor-tools",
- "sourceId": "D9UAVG",
- "title": "Optimizing full node costs with monitor tools",
- "description": "Running a full node is a fundamental component of participating in a decentralized network. However, the operational cost associated with running a full node can be prohibitively high, even for an archive node, it needs a lot of CPU/Memory and SSD disks. At our organization, we have successfully implemented a cost reduction strategy by using the pprof tool, along with grafana and prometheus in our node infrastructure.",
- "track": "Core Protocol",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
+ "id": "panel-source-code-verification",
+ "sourceId": "UJJPSH",
+ "title": "Panel: Source Code Verification",
+ "description": "Source code verification is the basis of trustlessness and transparency in blockchains.\r\nMany projects do source code verification but there hasn't been much collaboration and public interaction. The panel will bring members from the new collective \"Verifier Alliance\" together to create an open discussion.\r\n\r\nTopics include open-data and open-source, standardization, future challenges like state and data growth, multichain, monetization, and financial sustainability",
+ "track": "Developer Experience",
+ "type": "Panel",
+ "expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "performance optimization",
- "service level improvement"
+ "Source Code Verification",
+ "Block Explorers"
],
"tags": [
- "Architecture",
"Developer Infrastructure",
- "Best Practices",
- "service",
- "level",
- "improvement",
- "Architecture",
- "Best Practices",
- "Developer Infrastructure"
+ "User Experience",
+ "blocks",
+ "explorer",
+ "Developer Infrastructure",
+ "User Experience"
],
"language": "en",
"speakers": [
- "jsvisa"
+ "kirill-fedoseev",
+ "kaan-uzdogan",
+ "gary-thung",
+ "giacomo-barbieri"
],
"eventId": "devcon-7",
- "slot_start": 1731571800000,
- "slot_end": 1731572400000,
+ "slot_start": 1731493800000,
+ "slot_end": 1731497400000,
"slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1DOTMyJmIPI5tdLiG_5PoOmjA44ieroq22BSvZjFN9no"
+ "resources_presentation": "https://docs.google.com/presentation/d/1q-4HjJon6v4PjMBDOXwQwQS2B6fgTj_TjlTh6teEZd0"
},
"vector": [
0,
0,
0,
- 0,
6,
0,
0,
@@ -562957,6 +561767,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -563244,6 +562055,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -563332,8 +562144,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -563412,6 +562222,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -563669,6 +562481,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -563688,7 +562501,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -563707,11 +562519,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -563719,7 +562531,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -563801,6 +562612,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -563945,7 +562757,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -564094,7 +562905,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -564220,8 +563030,6 @@
0,
2,
0,
- 0,
- 0,
2,
0,
0,
@@ -564240,38 +563048,37 @@
},
{
"session": {
- "id": "oracles-for-number-values",
- "sourceId": "DBKAJX",
- "title": "Oracles for number values",
- "description": "We will overview the history and state of research on how to design a cryptoeconomic oracle that outputs a number value. One wants such tools for price oracles, but also for bringing other information on-chain, e.g. the damages to award from an on-chain insurance contract. We will look at approaches ranging from Vitalik's 2014 SchellingCoin proposal to ideas drawing from social choice theory, including based on recent research. We will explore tradeoffs including resistance to several attacks.",
- "track": "Cryptoeconomics",
+ "id": "passkeys-the-good-the-bad-the-ugly",
+ "sourceId": "XFLPAR",
+ "title": "Passkeys : the good, the bad, the ugly",
+ "description": "Passkeys are the new hype for easy onboarding, but it's a quite old protocol that has been hijacked for crypto purposes. We'll dig through the standard history, the potentially misleading security expectations, and see how to reverse engineer an implementation to validate its soundness",
+ "track": "Security",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Oracles"
+ "TEE"
],
"tags": [
- "Mechanism design",
- "oracle",
- "Mechanism",
- "design"
+ "Security",
+ "Account Abstraction",
+ "TEE",
+ "Account Abstraction",
+ "Security"
],
"language": "en",
"speakers": [
- "william-george"
+ "nicolas-bacca"
],
"eventId": "devcon-7",
- "slot_start": 1731659400000,
- "slot_end": 1731661200000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1gnmIdI5LzbPxcbx7iSARUelWaUg1VuvSthLIpccggM8"
+ "slot_start": 1731482400000,
+ "slot_end": 1731484200000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1qSDCPwnZ7bDT8RyjyUEMjDpMOU2yF_Nq0xmCkw7SprQ"
},
"vector": [
- 0,
- 0,
6,
0,
0,
@@ -564779,8 +563586,8 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -565021,6 +563828,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -565029,7 +563837,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -565072,6 +563879,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -565351,6 +564159,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -565460,9 +564269,6 @@
0,
0,
0,
- 2,
- 2,
- 2,
0,
0,
0,
@@ -565588,8 +564394,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -565605,42 +564411,40 @@
},
{
"session": {
- "id": "our-cypherpunk-approach-to-self-sovereign-digital-identity-does-not-work-in-real-world",
- "sourceId": "USJSPF",
- "title": "Our (Cypherpunk) approach to Self-Sovereign Digital Identity does not work in real world",
- "description": "For years our community is using cryptography and privacy-enhancing technologies trying to build solutions that will bring people control over their digital identities. How far have we got?\r\n\r\nThis talk would like to expose a gap that exists between our Cypherpunk approach to SSI and what a real world project needs / wants / can do.\r\n\r\nIf we want our SSI solutions to bring control over their digital identities back to people, it seems we need to take a different approach.",
- "track": "Cypherpunk & Privacy",
+ "id": "peerdas-in-grandine",
+ "sourceId": "YLLNEW",
+ "title": "PeerDAS in Grandine",
+ "description": "EPF project presentation on improving PeerDAS implementation in Grandine",
+ "track": "[CLS] EPF Day",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"tags": [
- "ssi",
- "Digital Sovereignty",
- "Identity",
- "Privacy"
- ],
- "keywords": [
- "ssi"
+ "Core Protocol",
+ "DAS",
+ "Data Availability",
+ "EIP4844"
],
- "duration": 442,
+ "keywords": [],
+ "duration": 714,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "7q2YD5QUHmo",
+ "sources_swarmHash": "b9c24999fe0efb631c31d2e6218f40dd82f654c4e6d6511549ece5006b3b141d",
+ "sources_youtubeId": "ZnigILUxWwo",
"sources_ipfsHash": "",
"sources_livepeerId": "",
- "sources_streamethId": "67349f549dbb7a90e13a18b4",
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67349f549dbb7a90e13a18b4.vtt",
- "transcript_text": " Hello everyone and thank you for being here. I know the party has already started. I'm looking at you, Carlos. Thanks again for being here. My name is Miros. Thank you for the nice introduction. I work in privado ID. And I want to talk a bit about why I think that our, and I say our because I consider myself to be part of the movement, cypherpunk approach to self-sovereign digital identity does not work. So we have been trying for years, right, to build tools that will protect people and to use all the cryptography and technology that we have, but how far have we actually got? We are offering full user control, privacy, decentralization, anonymity, and business that is actually building applications for people to use. And I'm not talking about us, right, in a battery bubble. I'm talking about people here on the street. Well, these businesses, they want UX, they want integration, they want compliance. What are the key challenges? Well, these, right? First one is the usability. Talk about private keys, but if I look at the initials concept, multi-chain, a lot of words that are un-understandable for a lot of people, right? Ease of integration. If we are talking about people that need to use our technology, or let's say businesses to use our technology, decentralization, most probably not going to work or comes with a lot of hurdles, right? And we need to work with legacy systems if we want billions of people actually to benefit from all this. Compliance, sadly, but we know that the KYC, AML, and other stuff are required, right? Like it or not. So the cypherpunk vision of total privacy and anonymity is an ideal, right? And I'm not saying to kill that, right? We need to keep the ideal there and work toward that, but we need to change some stuff. I call for an incremental approach. I'm just going to take one example here, right, an opportunity, but there are much more of these out there, being the European Digital Identity Incentive. So they recognize the problem, right, that the privacy of the regular people, of the common people, is in danger. And their solution is not ideal, right? They offer selective disclosure, data minimization, verifiable credentials. It's a good step forward, but it's not cypherpunk, right? But I think we should join this. We should hop on the bandwagon, because we can influence things. We can try to change some stuff. And actually, this is why I'm here, right? I would like that this debate happens here between all of us and all of you that are out there on the Internet. So what we could win, right? We could promote privacy for standards. We could encourage more adoption. We can actually have more private and decentralized alternatives. Jordi Bailina yesterday in his talk mentioned, and I agree with that, although it's not ideal, right? I would rather trust my private data with a government than with a corporation. Again, it's not ideal, but it is a step forward, right? And no, this does not mean that we stop fighting, right? I invite you all to think critically about building, advocating, or using, right, the solutions that are both streaming towards cypherpunk, right, but are adaptable and can be used in real world, right? Let's please try to balance, right, idealism with practical constraints. So we can achieve more with what we have today streaming towards the ideal world, right? There were a lot of talks, and I like the talk that was here, the previous from Evian and the other one, right? And yesterday, there were a lot of also talks about cypherpunk movement. It is important. All of you need to join if you are not part of that. But again, I advocate for an approach that is incremental, that we think not only about ourselves, but we think about the people that are out there on the street. That doesn't mean that we do not need Tor, that we do not need all the tools for journalists, for people that are doing really important things. That, yes, but also yes for the common people, right? The struggle continues. I'm Miros. Thank you. Thank you very much. Thank you. So we will have some time to ask a few questions. Raise your hand if you have any questions. I can throw the red square at you. Oh, you want to? No, no, no. I mean, I'm challenging. Oh, okay. Any questions? Do you want to throw it? No, no. I don't want to hurt the CSO of my company. Maros, obviously there are a lot of examples that you've described of ways in which things are suboptimal. Now, ourselves aside, who else is doing it right? government leaders, are there enterprises, are there idealists or leaders who we should look to in our institutional structures as potential partners? I think yes. I mean, whoever was on a bunch of all these talks that happened, and they are going to happen tomorrow and the day after, there are people, right, that are trying to do all this. And, of course, I know our team best, and we are trying the best that we can. But I really like, for example, having the initiative coming from the European Union. That's 650 million people that tomorrow can have privacy towards Amazon. Yes, where do I sign, right? But that's not the end game. So there are people, there are things that we can do and and that's it right no you're right absolutely that's a great call out European Union and also shout out to the etherium foundation for showing up this week on this topic too yes and that's a drop mic, literally. Any more questions? Okay. No? Well, thank you very much. Thank you. Please give a nice round of applause to Milos. Thank you.",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731494400000,
- "slot_end": 1731495000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1tieWVdz2ClCZUAnL4cwbHgtEkk_tNIfgbdodCv6BfoY",
+ "slot_start": 1731483000000,
+ "slot_end": 1731483900000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Iiq2VFXcakCQ4LfaHpWejg013im1G0mu9_E24tzaarE",
"resources_slides": null,
"speakers": [
- "miros"
+ "hangleang"
]
},
"vector": [
@@ -565649,8 +564453,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -565661,6 +564463,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -566413,6 +565216,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -566445,10 +565249,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -566460,9 +565260,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -566512,7 +565314,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -566750,6 +565551,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -566837,7 +565639,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -566961,12 +565762,12 @@
0,
2,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -566979,46 +565780,38 @@
},
{
"session": {
- "id": "panel-source-code-verification",
- "sourceId": "UJJPSH",
- "title": "Panel: Source Code Verification",
- "description": "Source code verification is the basis of trustlessness and transparency in blockchains.\r\nMany projects do source code verification but there hasn't been much collaboration and public interaction. The panel will bring members from the new collective \"Verifier Alliance\" together to create an open discussion.\r\n\r\nTopics include open-data and open-source, standardization, future challenges like state and data growth, multichain, monetization, and financial sustainability",
- "track": "Developer Experience",
- "type": "Panel",
- "expertise": "Beginner",
+ "id": "peerdas-metrics-specifications",
+ "sourceId": "UYPWVK",
+ "title": "PeerDAS metrics specifications",
+ "description": "The PeerDAS Metrics Specifications help make testing more efficient and straightforward by creating standard metrics for Consensus clients. With a unified Grafana dashboard, teams can monitor performance in real-time, compare client data side by side, and quickly spot issues. This approach makes troubleshooting faster, supports research, and encourages teamwork, helping strengthen the Ethereum ecosystem and improve scalability.",
+ "track": "[CLS] EPF Day",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Source Code Verification",
- "Block Explorers"
+ "DevOps"
],
"tags": [
- "Developer Infrastructure",
- "User Experience",
- "blocks",
- "explorer",
- "Developer Infrastructure",
- "User Experience"
+ "Core Protocol",
+ "Testing",
+ "Tooling"
],
"language": "en",
"speakers": [
- "kirill-fedoseev",
- "kaan-uzdogan",
- "gary-thung",
- "giacomo-barbieri"
+ "ekaterina-riazantseva"
],
"eventId": "devcon-7",
- "slot_start": 1731493800000,
- "slot_end": 1731497400000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1q-4HjJon6v4PjMBDOXwQwQS2B6fgTj_TjlTh6teEZd0"
+ "slot_start": 1731483900000,
+ "slot_end": 1731484800000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1K_w0rS7tGijHA1ThVt6Mzpg7shFMcaOpglVD01dIMPQ"
},
"vector": [
0,
0,
0,
- 6,
0,
0,
0,
@@ -567031,6 +565824,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -567066,7 +565861,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -567355,7 +566149,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -567527,7 +566320,6 @@
0,
0,
6,
- 6,
0,
0,
0,
@@ -567783,10 +566575,11 @@
0,
0,
0,
- 6,
0,
0,
+ 2,
0,
+ 2,
0,
0,
0,
@@ -567821,7 +566614,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -567914,7 +566706,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -568007,6 +566798,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -568209,7 +567001,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -568328,9 +567119,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
2,
0,
@@ -568350,45 +567141,47 @@
},
{
"session": {
- "id": "passkeys-the-good-the-bad-the-ugly",
- "sourceId": "XFLPAR",
- "title": "Passkeys : the good, the bad, the ugly",
- "description": "Passkeys are the new hype for easy onboarding, but it's a quite old protocol that has been hijacked for crypto purposes. We'll dig through the standard history, the potentially misleading security expectations, and see how to reverse engineer an implementation to validate its soundness",
- "track": "Security",
- "type": "Talk",
+ "id": "permissionless-p2p-with-the-waku-network",
+ "sourceId": "N9WRM3",
+ "title": "Permissionless P2P with The Waku Network",
+ "description": "This workshop will be oriented around showcasing how p2p networks are pivotal for dapps and just Privacy oriented applications. We will show how Waku can be used to strengthen many concerns about censorship resistance and decentralization. Another section of workshop will be about conscious choice of tradeoffs and those that are present in Waku or any other p2p network. We will try to leave you with some patterns that can be implemented into your daily development and reasoning.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "TEE"
+ "p2p",
+ "infra"
],
"tags": [
- "Security",
- "Account Abstraction",
- "TEE",
- "Account Abstraction",
- "Security"
+ "Developer Infrastructure",
+ "Privacy",
+ "DePIN",
+ "infra",
+ "p2p",
+ "DePIN",
+ "Developer Infrastructure",
+ "Privacy"
],
"language": "en",
"speakers": [
- "nicolas-bacca"
+ "sasha"
],
"eventId": "devcon-7",
- "slot_start": 1731482400000,
- "slot_end": 1731484200000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1qSDCPwnZ7bDT8RyjyUEMjDpMOU2yF_Nq0xmCkw7SprQ"
+ "slot_start": 1731571200000,
+ "slot_end": 1731576600000,
+ "slot_roomId": "classroom-d",
+ "resources_presentation": "https://docs.google.com/presentation/d/1-0QAKQAwAZ11MiH9PyyPFFxZJJ76rz1xsmKj_FWlbEM"
},
"vector": [
- 6,
- 0,
- 0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -569133,10 +567926,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -569158,6 +567947,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -569184,12 +567974,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -569251,6 +568041,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -569432,6 +568223,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -569465,7 +568257,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -569574,6 +568365,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -569698,9 +568490,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -569716,41 +568508,33 @@
},
{
"session": {
- "id": "peerdas-in-grandine",
- "sourceId": "YLLNEW",
- "title": "PeerDAS in Grandine",
- "description": "EPF project presentation on improving PeerDAS implementation in Grandine",
- "track": "[CLS] EPF Day",
- "type": "Lightning Talk",
+ "id": "pessimists-archive-presents-the-franklin-fallacy-why-we-misjudge-new-technologies",
+ "sourceId": "W7MVPA",
+ "title": "Pessimists Archive Presents: The Franklin Fallacy, Why We Misjudge New Technologies",
+ "description": "People often dismiss emerging technologies by focusing only on their current limitations, overlooking their potential evolution. This tendency, seen throughout history—from the telegraph to Ethereum—stems from what can be called “The Franklin Fallacy.” When asked about the purpose of a hot air balloon, Benjamin Franklin famously responded, \"What good is a newborn baby?\" highlighting how judging a technology in its infancy is shortsighted. This talk explores the psychology of this fallacy.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
"expertise": "Beginner",
- "audience": "Engineering",
+ "audience": "Academic",
"featured": false,
"doNotRecord": false,
+ "keywords": [
+ "Technological",
+ "Acceptance"
+ ],
"tags": [
- "Core Protocol",
- "DAS",
- "Data Availability",
- "EIP4844"
+ "e/acc",
+ "Marketing"
],
- "keywords": [],
- "duration": 714,
"language": "en",
- "sources_swarmHash": "b9c24999fe0efb631c31d2e6218f40dd82f654c4e6d6511549ece5006b3b141d",
- "sources_youtubeId": "ZnigILUxWwo",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731483000000,
- "slot_end": 1731483900000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1Iiq2VFXcakCQ4LfaHpWejg013im1G0mu9_E24tzaarE",
- "resources_slides": null,
"speakers": [
- "hangleang"
- ]
+ "louis-anslow"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731555000000,
+ "slot_end": 1731556800000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1BYWK_IatacBdd2r84kKv_IWDoGpsDqXH7RNIaxf7qqQ"
},
"vector": [
0,
@@ -569759,6 +568543,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -569768,9 +568553,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -570524,7 +569306,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -570568,11 +569349,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -570663,6 +569442,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -570795,6 +569575,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -570860,7 +569641,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -571068,7 +569848,6 @@
0,
0,
0,
- 2,
0,
2,
0,
@@ -571081,6 +569860,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0
@@ -571088,33 +569869,34 @@
},
{
"session": {
- "id": "peerdas-metrics-specifications",
- "sourceId": "UYPWVK",
- "title": "PeerDAS metrics specifications",
- "description": "The PeerDAS Metrics Specifications help make testing more efficient and straightforward by creating standard metrics for Consensus clients. With a unified Grafana dashboard, teams can monitor performance in real-time, compare client data side by side, and quickly spot issues. This approach makes troubleshooting faster, supports research, and encourages teamwork, helping strengthen the Ethereum ecosystem and improve scalability.",
- "track": "[CLS] EPF Day",
+ "id": "play-a-massive-onchain-war-game-mud-day-demo",
+ "sourceId": "PG3VAG",
+ "title": "Play a massive onchain war game! - MUD Day Demo",
+ "description": "Play Battle for Blockchain, an onchain war game with us. Become the commander of armies and storm your enemies. Collaborate with friends to obliterate opponents and win fortune.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Hobby",
"featured": false,
"doNotRecord": false,
"keywords": [
- "DevOps"
+ "",
+ ""
],
"tags": [
- "Core Protocol",
- "Testing",
- "Tooling"
+ "Autonomous World",
+ "Coordination",
+ "Gaming"
],
"language": "en",
"speakers": [
- "ekaterina-riazantseva"
+ "stokarz"
],
"eventId": "devcon-7",
- "slot_start": 1731483900000,
- "slot_end": 1731484800000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1K_w0rS7tGijHA1ThVt6Mzpg7shFMcaOpglVD01dIMPQ"
+ "slot_start": 1731554700000,
+ "slot_end": 1731555000000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1UNKZFzRMqNLX4iLJO6NRMaXRhwd2RgXojdoLtHJGj3w"
},
"vector": [
0,
@@ -571129,9 +569911,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -571632,9 +570411,8 @@
0,
0,
0,
- 6,
- 0,
0,
+ 6,
0,
0,
0,
@@ -571888,9 +570666,7 @@
0,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
@@ -571982,6 +570758,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -572025,6 +570803,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -572110,7 +570889,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -572430,7 +571208,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -572443,6 +571220,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -572452,41 +571231,45 @@
},
{
"session": {
- "id": "permissionless-p2p-with-the-waku-network",
- "sourceId": "N9WRM3",
- "title": "Permissionless P2P with The Waku Network",
- "description": "This workshop will be oriented around showcasing how p2p networks are pivotal for dapps and just Privacy oriented applications. We will show how Waku can be used to strengthen many concerns about censorship resistance and decentralization. Another section of workshop will be about conscious choice of tradeoffs and those that are present in Waku or any other p2p network. We will try to leave you with some patterns that can be implemented into your daily development and reasoning.",
- "track": "Cypherpunk & Privacy",
+ "id": "polynomial-commitment-schemes-for-zero-knowledge-proof-systems-a-hands-on-workshop",
+ "sourceId": "QAQAUX",
+ "title": "Polynomial Commitment Schemes for Zero-Knowledge Proof Systems: A Hands-on Workshop",
+ "description": "In this workshop, we will compare three distinct classes of Polynomial Commitment Schemes employed in various zero-knowledge proof systems: pairings-based (e.g., KZG), discrete logarithm-based (e.g., IPA), and hash function-based (e.g., FRI). We will explore their mathematical constructions, properties, and trade-offs. Participants will engage in hands-on proof-of-concept implementations, gaining practical experience of these advanced cryptographic protocols.",
+ "track": "Applied Cryptography",
"type": "Workshop",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developer",
"featured": false,
- "doNotRecord": false,
+ "doNotRecord": true,
"keywords": [
- "p2p",
- "infra"
+ "cryptographic primitives",
+ "implementation"
],
"tags": [
- "Developer Infrastructure",
- "Privacy",
- "DePIN",
- "infra",
- "p2p",
- "DePIN",
- "Developer Infrastructure",
- "Privacy"
+ "Zk Rollups",
+ "Zero-Knowledge",
+ "Cryptography",
+ "implementation",
+ "Cryptography",
+ "Zero-Knowledge",
+ "Zk Rollups"
],
"language": "en",
"speakers": [
- "sasha"
+ "giuseppe"
],
"eventId": "devcon-7",
- "slot_start": 1731571200000,
- "slot_end": 1731576600000,
+ "slot_start": 1731645000000,
+ "slot_end": 1731650400000,
"slot_roomId": "classroom-d",
- "resources_presentation": "https://docs.google.com/presentation/d/1-0QAKQAwAZ11MiH9PyyPFFxZJJ76rz1xsmKj_FWlbEM"
+ "resources_presentation": "https://docs.google.com/presentation/d/1L15TG4XE9h8o3WvPj5ksj6cdCnNYdYuY1dI9gWq3GEg"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -572996,6 +571779,9 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
0,
0,
0,
@@ -573003,7 +571789,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -573241,6 +572026,12 @@
0,
0,
0,
+ 6,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -573261,7 +572052,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -573355,7 +572145,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -573538,7 +572327,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -573667,6 +572455,33 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -573682,46 +572497,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -573804,9 +572579,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -573822,33 +572597,35 @@
},
{
"session": {
- "id": "pessimists-archive-presents-the-franklin-fallacy-why-we-misjudge-new-technologies",
- "sourceId": "W7MVPA",
- "title": "Pessimists Archive Presents: The Franklin Fallacy, Why We Misjudge New Technologies",
- "description": "People often dismiss emerging technologies by focusing only on their current limitations, overlooking their potential evolution. This tendency, seen throughout history—from the telegraph to Ethereum—stems from what can be called “The Franklin Fallacy.” When asked about the purpose of a hot air balloon, Benjamin Franklin famously responded, \"What good is a newborn baby?\" highlighting how judging a technology in its infancy is shortsighted. This talk explores the psychology of this fallacy.",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Academic",
+ "id": "popcraft-mud-day-demo",
+ "sourceId": "UDJFDV",
+ "title": "PopCraft - MUD Day Demo",
+ "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. PopCraft is a fully on-chain casual click-based game integrating gameplay with financial elements. Currently in single-player mode, it plans to expand to multiplayer. Built on composability, PopCraft uses PixeLAW, TCM, and Redswap. In-game item issuance and trading are decentralized, transparent, and open, allowing seamless integration of any ERC-20 token projects and DEX.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Technological",
- "Acceptance"
+ "Fully",
+ "on-chain",
+ "game"
],
"tags": [
- "e/acc",
- "Marketing"
+ "Autonomous World",
+ "Gaming",
+ "Not financial"
],
"language": "en",
"speakers": [
- "louis-anslow"
+ "ck"
],
"eventId": "devcon-7",
- "slot_start": 1731555000000,
- "slot_end": 1731556800000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1BYWK_IatacBdd2r84kKv_IWDoGpsDqXH7RNIaxf7qqQ"
+ "slot_start": 1731557100000,
+ "slot_end": 1731557400000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/12K7Vn_cc7jQu6WzJS3EQxpVW_8a_ylzYwi82LxCmSBw"
},
"vector": [
0,
@@ -573857,15 +572634,13 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -574712,6 +573487,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -574759,9 +573536,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -574839,6 +573613,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -574893,7 +573668,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -575164,20 +573938,20 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -575186,34 +573960,27 @@
},
{
"session": {
- "id": "play-a-massive-onchain-war-game-mud-day-demo",
- "sourceId": "PG3VAG",
- "title": "Play a massive onchain war game! - MUD Day Demo",
- "description": "Play Battle for Blockchain, an onchain war game with us. Become the commander of armies and storm your enemies. Collaborate with friends to obliterate opponents and win fortune.",
+ "id": "porting-dark-forest-to-mud-mud-day-demo",
+ "sourceId": "VBS9CJ",
+ "title": "Porting Dark Forest to MUD - MUD Day Demo",
+ "description": "We recently ported Dark Forest to the MUD engine and would like to share some of the insights we gained during this process with everyone.",
"track": "[CLS] MUD Community-Led Session, by 0xPARC",
"type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Hobby",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "",
- ""
- ],
- "tags": [
- "Autonomous World",
- "Coordination",
- "Gaming"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
"speakers": [
- "stokarz"
+ "ddy"
],
"eventId": "devcon-7",
- "slot_start": 1731554700000,
- "slot_end": 1731555000000,
+ "slot_start": 1731556200000,
+ "slot_end": 1731556500000,
"slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1UNKZFzRMqNLX4iLJO6NRMaXRhwd2RgXojdoLtHJGj3w"
+ "resources_presentation": "https://docs.google.com/presentation/d/14aQQNVk55JWYMHYKeZITv12OkJVvgS-kWDNWXp6cpX4"
},
"vector": [
0,
@@ -575732,8 +574499,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -576078,8 +574843,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -576123,7 +574886,7 @@
0,
0,
0,
- 2,
+ 0,
0,
0,
0,
@@ -576534,13 +575297,14 @@
2,
0,
0,
+ 2,
+ 0,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -576551,38 +575315,45 @@
},
{
"session": {
- "id": "polynomial-commitment-schemes-for-zero-knowledge-proof-systems-a-hands-on-workshop",
- "sourceId": "QAQAUX",
- "title": "Polynomial Commitment Schemes for Zero-Knowledge Proof Systems: A Hands-on Workshop",
- "description": "In this workshop, we will compare three distinct classes of Polynomial Commitment Schemes employed in various zero-knowledge proof systems: pairings-based (e.g., KZG), discrete logarithm-based (e.g., IPA), and hash function-based (e.g., FRI). We will explore their mathematical constructions, properties, and trade-offs. Participants will engage in hands-on proof-of-concept implementations, gaining practical experience of these advanced cryptographic protocols.",
- "track": "Applied Cryptography",
- "type": "Workshop",
+ "id": "postcards-from-the-cutting-edge-of-gas-research-what-you-dont-know-can-hurt-you-and-your-users",
+ "sourceId": "X8VZDJ",
+ "title": "Postcards from the cutting edge of Gas research: what you don’t know can hurt you & your users",
+ "description": "In July of 2024, we shared original research describing how the interaction between privately transmitted transactions and altruistic self-built blocks unexpectedly increase Base Fee volatility (see references below). We also warned that this effect would likely get more pronounced as private transaction share continues to grow. In this session we will revisit our original findings but with 4 months of additional data and deeper investigative research. Has gas price volatility increased as predi",
+ "track": "Usability",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Engineering",
"featured": false,
- "doNotRecord": true,
- "keywords": [
- "cryptographic primitives",
- "implementation"
- ],
+ "doNotRecord": false,
"tags": [
- "Zk Rollups",
- "Zero-Knowledge",
- "Cryptography",
- "implementation",
- "Cryptography",
- "Zero-Knowledge",
- "Zk Rollups"
+ "eip-4844",
+ "Gas",
+ "Layer 1",
+ "UI/UX"
],
- "language": "en",
- "speakers": [
- "giuseppe"
+ "keywords": [
+ "1559",
+ "Blobs",
+ "4844"
],
+ "duration": 434,
+ "language": "en",
+ "sources_swarmHash": "a727fa169242eec4b80126341a1150efb4a45bc5a1b4a6a288a8c0e8bf19c107",
+ "sources_youtubeId": "NKGOZ154rPM",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731645000000,
- "slot_end": 1731650400000,
- "slot_roomId": "classroom-d",
- "resources_presentation": "https://docs.google.com/presentation/d/1L15TG4XE9h8o3WvPj5ksj6cdCnNYdYuY1dI9gWq3GEg"
+ "slot_start": 1731407400000,
+ "slot_end": 1731408000000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1AzgmOOm16-VrlFGtmsr5MOvsAabE-h1nClU9xydV9I4",
+ "resources_slides": null,
+ "speakers": [
+ "matt-cutler"
+ ]
},
"vector": [
0,
@@ -576593,8 +575364,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -577349,11 +576118,9 @@
0,
0,
0,
- 6,
- 6,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -577397,6 +576164,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -577406,7 +576174,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -577565,6 +576332,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -577779,9 +576547,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -577902,9 +576670,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -577920,35 +576688,27 @@
},
{
"session": {
- "id": "popcraft-mud-day-demo",
- "sourceId": "UDJFDV",
- "title": "PopCraft - MUD Day Demo",
- "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. PopCraft is a fully on-chain casual click-based game integrating gameplay with financial elements. Currently in single-player mode, it plans to expand to multiplayer. Built on composability, PopCraft uses PixeLAW, TCM, and Redswap. In-game item issuance and trading are decentralized, transparent, and open, allowing seamless integration of any ERC-20 token projects and DEX.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Community",
+ "id": "power-centralisation-and-liberal-values",
+ "sourceId": "EJUTA3",
+ "title": "Power, Centralisation and Liberal Values",
+ "description": "Western liberalism has struggled to fulfill its ideals, facing issues of selective enforcement, systemic inequities, and economic centralization. This has weakened global trust in democratic principles. The challenge now is to create structures that genuinely decentralize power and promote equity.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Fully",
- "on-chain",
- "game"
- ],
- "tags": [
- "Autonomous World",
- "Gaming",
- "Not financial"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
"speakers": [
- "ck"
+ "ahmed-gatnash"
],
"eventId": "devcon-7",
- "slot_start": 1731557100000,
- "slot_end": 1731557400000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/12K7Vn_cc7jQu6WzJS3EQxpVW_8a_ylzYwi82LxCmSBw"
+ "slot_start": 1731651000000,
+ "slot_end": 1731652200000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Xh5mjcx0whviYN-YFZ-Y0vVWcycLpTyfwEI-cWNKTMk"
},
"vector": [
0,
@@ -577957,13 +576717,13 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -578469,9 +577229,17 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
- 6,
0,
0,
0,
@@ -578813,8 +577581,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -578940,13 +577706,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -579266,6 +578025,7 @@
0,
2,
0,
+ 2,
0,
0,
0,
@@ -579273,9 +578033,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -579286,31 +578043,37 @@
},
{
"session": {
- "id": "porting-dark-forest-to-mud-mud-day-demo",
- "sourceId": "VBS9CJ",
- "title": "Porting Dark Forest to MUD - MUD Day Demo",
- "description": "We recently ported Dark Forest to the MUD engine and would like to share some of the insights we gained during this process with everyone.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Lightning Talk",
- "expertise": "",
- "audience": "Engineering",
+ "id": "practical-endgame-on-issuance-policy",
+ "sourceId": "TQMWK9",
+ "title": "Practical endgame on issuance policy",
+ "description": "A practical endgame on issuance policy stops the growth in stake while guaranteeing proper consensus incentives and positive regular rewards to solo stakers. Viable reward curves for this endgame are presented. Motivations, impacts and potential downsides of an issuance reduction are in focus. A tangible framework is also introduced: never exceed an issuance rate of 0.5%. A stringent cap on issuance caps the inflation rate, solidifying ETH as trustless sound money with robust economic security.",
+ "track": "Cryptoeconomics",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [],
- "tags": [],
+ "tags": [
+ "Consensus",
+ "Economics",
+ "Staking",
+ "Tokenomics"
+ ],
"language": "en",
"speakers": [
- "ddy"
+ "anders-elowsson"
],
"eventId": "devcon-7",
- "slot_start": 1731556200000,
- "slot_end": 1731556500000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/14aQQNVk55JWYMHYKeZITv12OkJVvgS-kWDNWXp6cpX4"
+ "slot_start": 1731558600000,
+ "slot_end": 1731560400000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1xmwhrvV65FuGDVnNb8_zGgVoMM4-pg6gMEP0t1Iw-OU"
},
"vector": [
0,
0,
+ 6,
0,
0,
0,
@@ -579321,9 +578084,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -580065,6 +578825,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -580094,6 +578855,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -580102,6 +578864,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -580186,6 +578949,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -580617,13 +579381,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
2,
@@ -580634,58 +579398,40 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "postcards-from-the-cutting-edge-of-gas-research-what-you-dont-know-can-hurt-you-and-your-users",
- "sourceId": "X8VZDJ",
- "title": "Postcards from the cutting edge of Gas research: what you don’t know can hurt you & your users",
- "description": "In July of 2024, we shared original research describing how the interaction between privately transmitted transactions and altruistic self-built blocks unexpectedly increase Base Fee volatility (see references below). We also warned that this effect would likely get more pronounced as private transaction share continues to grow. In this session we will revisit our original findings but with 4 months of additional data and deeper investigative research. Has gas price volatility increased as predi",
- "track": "Usability",
+ "id": "prediction-market-panel",
+ "sourceId": "CCZCSH",
+ "title": "Prediction market panel",
+ "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
- "expertise": "Intermediate",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "eip-4844",
- "Gas",
- "Layer 1",
- "UI/UX"
- ],
- "keywords": [
- "1559",
- "Blobs",
- "4844"
- ],
- "duration": 434,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "a727fa169242eec4b80126341a1150efb4a45bc5a1b4a6a288a8c0e8bf19c107",
- "sources_youtubeId": "NKGOZ154rPM",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731407400000,
- "slot_end": 1731408000000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1AzgmOOm16-VrlFGtmsr5MOvsAabE-h1nClU9xydV9I4",
- "resources_slides": null,
"speakers": [
- "matt-cutler"
- ]
+ "robin-hanson",
+ "martin-k",
+ "joey-krug",
+ "cj",
+ "kas"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731563400000,
+ "slot_end": 1731564300000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Rm-aNAjKTe4WozwIfgJQZhQN1chtswB5-fuDukQWE5k"
},
"vector": [
0,
+ 6,
0,
0,
0,
@@ -580693,10 +579439,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -580895,6 +579637,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -581208,6 +579951,9 @@
0,
0,
6,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -581452,7 +580198,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -581496,7 +580241,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -581665,7 +580409,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -581882,7 +580625,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -581998,8 +580740,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
2,
@@ -582020,27 +580762,33 @@
},
{
"session": {
- "id": "power-centralisation-and-liberal-values",
- "sourceId": "EJUTA3",
- "title": "Power, Centralisation and Liberal Values",
- "description": "Western liberalism has struggled to fulfill its ideals, facing issues of selective enforcement, systemic inequities, and economic centralization. This has weakened global trust in democratic principles. The challenge now is to create structures that genuinely decentralize power and promote equity.",
+ "id": "privacy-enabled-smart-contract-driven-fair-and-transparent-reward-mechanism-in-federated-ai",
+ "sourceId": "LKD3RG",
+ "title": "Privacy enabled, Smart Contract driven Fair and transparent reward mechanism in Federated AI",
+ "description": "Federated learning enables multiple parties to contribute their locally trained models to an aggregation server, which securely combines individual models into a global one. However, it lacks a fair, verifiable, and proportionate reward (or penalty) mechanism for each contributor. Implementing a smart contract-based contribution analysis framework for federated learning on a privacy-enabled Ethereum L2 can address this challenge, and build the economics of federated learning public chain.",
"track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Federated AI",
+ "Smart Contracts",
+ "Transparency"
+ ],
+ "tags": [
+ "transparency"
+ ],
"language": "en",
"speakers": [
- "ahmed-gatnash"
+ "sudhir-upadhyay"
],
"eventId": "devcon-7",
- "slot_start": 1731651000000,
- "slot_end": 1731652200000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1Xh5mjcx0whviYN-YFZ-Y0vVWcycLpTyfwEI-cWNKTMk"
+ "slot_start": 1731564600000,
+ "slot_end": 1731565200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1aXt8K7kJm7xJ0limjmVm0ZVioUUzgILAGxnm6NBfVoU"
},
"vector": [
0,
@@ -582566,11 +581314,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -583238,6 +581983,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -583355,10 +582101,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
2,
0,
@@ -583372,47 +582118,48 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "practical-endgame-on-issuance-policy",
- "sourceId": "TQMWK9",
- "title": "Practical endgame on issuance policy",
- "description": "A practical endgame on issuance policy stops the growth in stake while guaranteeing proper consensus incentives and positive regular rewards to solo stakers. Viable reward curves for this endgame are presented. Motivations, impacts and potential downsides of an issuance reduction are in focus. A tangible framework is also introduced: never exceed an issuance rate of 0.5%. A stringent cap on issuance caps the inflation rate, solidifying ETH as trustless sound money with robust economic security.",
- "track": "Cryptoeconomics",
+ "id": "privacy-first-cbdcs",
+ "sourceId": "TWMAWN",
+ "title": "Privacy-First CBDCs",
+ "description": "This talk explores how central bank digital currencies (CBDCs) can leverage zero-knowledge proofs (ZKPs) and Ethereum to create privacy-centric monetary systems. We'll examine how ZKPs enable robust AML/CTF compliance while preserving user privacy, discuss the benefits of Ethereum deployment for financial inclusion and innovation, and showcase how these technologies could revolutionize digital currency design. Future CBDCs can and should offer unparalleled privacy, security, and functionality.",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Community",
+ "expertise": "Beginner",
+ "audience": "Lobby",
"featured": false,
"doNotRecord": false,
- "keywords": [],
+ "keywords": [
+ "CBDC"
+ ],
"tags": [
- "Consensus",
- "Economics",
- "Staking",
- "Tokenomics"
+ "Payment",
+ "Privacy",
+ "Zero-Knowledge"
],
"language": "en",
"speakers": [
- "anders-elowsson"
+ "joe-andrews",
+ "andre-omietanski"
],
"eventId": "devcon-7",
- "slot_start": 1731558600000,
- "slot_end": 1731560400000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1xmwhrvV65FuGDVnNb8_zGgVoMM4-pg6gMEP0t1Iw-OU"
+ "slot_start": 1731400200000,
+ "slot_end": 1731402000000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1yAUh-BkJ1oE5n2L_-NknKAtAJ9okKkjhrA-_VvME4rw"
},
"vector": [
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -583630,6 +582377,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -584163,25 +582911,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -584193,7 +582926,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -584202,7 +582934,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -584312,6 +583043,43 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -584697,37 +583465,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -584736,45 +583473,76 @@
0,
0,
0,
- 0
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2
]
},
{
"session": {
- "id": "prediction-market-panel",
- "sourceId": "CCZCSH",
- "title": "Prediction market panel",
- "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "id": "privacy-preserving-groups",
+ "sourceId": "LSA3JK",
+ "title": "Privacy-Preserving Groups",
+ "description": "This talk will explore the concept of privacy-preserving groups and the challenges associated with managing them. It will cover different ideas to add anti-sybil mechanisms to enhance group security and trust. The presentation will also highlight real-world projects working on it and provide practical use cases to illustrate their application and impact.",
+ "track": "Applied Cryptography",
"type": "Lightning Talk",
- "expertise": "",
+ "expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
- "language": "en",
- "speakers": [
- "robin-hanson",
- "martin-k",
- "joey-krug",
- "cj",
- "kas"
+ "tags": [
+ "Tooling",
+ "DAO",
+ "Privacy",
+ "Anonymity",
+ "Identity",
+ "Open Source Software",
+ "ZKP",
+ "Zero-Knowledge",
+ "Use cases of cryptography",
+ "Public good",
+ "User Experience",
+ "groups",
+ "Anonymity",
+ "DAO",
+ "Identity",
+ "Open Source Software",
+ "Privacy",
+ "Public good",
+ "Tooling",
+ "Use cases of cryptography",
+ "User Experience",
+ "Zero-Knowledge",
+ "ZKP"
+ ],
+ "keywords": [
+ "Groups"
],
+ "duration": 464,
+ "language": "en",
+ "sources_swarmHash": "18b4db550bcad65fa27ad24340bd8c75da7a5d04c9944d8303de3e690ebbdaf8",
+ "sources_youtubeId": "dWQWoqJVfn8",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330caf3a168eb535f0cb29.vtt",
+ "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the theorem foundation and today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Attestation service, CKE, MelTLS, Notary, and POP. So some projects can be useful for privacy-preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-CV2. So the three main ideas from this presentation that I would like you to remember are privacy preserving groups can ideas from this presentation that I would like you to remember are like privacy preserving groups can be used to verify credentials and to have a better user experience in your applications also that you can combine different anti-civil mechanisms to have a stronger one and that's a very important is maybe it's not your case but for your, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. This works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes, Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this, the commitment to a Bandala group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with, yeah, the members in your group any other questions it's over there I see some people wearing the mere cat hat but unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, and there might be a reason to remove someone forcefully, are there any practical way to do that? Yeah, yeah, there is. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is a way, an easy way, if you are using code or not. Can you explain the mechanic behind, like how can you maintain privacy of everyone, and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean the person, it's a commitment so people don't know like who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and the admin can remove people see ya",
"eventId": "devcon-7",
- "slot_start": 1731563400000,
- "slot_end": 1731564300000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1Rm-aNAjKTe4WozwIfgJQZhQN1chtswB5-fuDukQWE5k"
+ "slot_start": 1731396600000,
+ "slot_end": 1731397200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/13v7xDojqK_R5sq5GZJLvGNitJNJ0JqrztXhZYzs0pXM",
+ "resources_slides": null,
+ "speakers": [
+ "vivian-plasencia"
+ ]
},
"vector": [
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -584785,6 +583553,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -585030,7 +583799,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -585293,14 +584061,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -585309,6 +584069,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -585543,18 +584304,23 @@
0,
0,
0,
+ 6,
0,
0,
0,
+ 6,
0,
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
+ 2,
0,
0,
0,
@@ -585575,6 +584341,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -585600,6 +584367,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -585622,8 +584390,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -585631,12 +584401,14 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -585964,6 +584736,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -586084,7 +584857,6 @@
0,
2,
0,
- 0,
2,
0,
0,
@@ -586103,38 +584875,40 @@
},
{
"session": {
- "id": "privacy-enabled-smart-contract-driven-fair-and-transparent-reward-mechanism-in-federated-ai",
- "sourceId": "LKD3RG",
- "title": "Privacy enabled, Smart Contract driven Fair and transparent reward mechanism in Federated AI",
- "description": "Federated learning enables multiple parties to contribute their locally trained models to an aggregation server, which securely combines individual models into a global one. However, it lacks a fair, verifiable, and proportionate reward (or penalty) mechanism for each contributor. Implementing a smart contract-based contribution analysis framework for federated learning on a privacy-enabled Ethereum L2 can address this challenge, and build the economics of federated learning public chain.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "id": "prize-worthy-an-ethereum-python-hackathon-guide",
+ "sourceId": "73J9ZG",
+ "title": "Prize-Worthy: An Ethereum Python Hackathon Guide",
+ "description": "An interactive and beginner-friendly Ethereum Python Speedrun tailored for hackathons, hosted by the EF Python team. Quickly get up to speed with fundamental building blocks, then stack them into a live application. By the end of this workshop, you'll have a clear idea of how to get your own projects off the ground.",
+ "track": "Developer Experience",
+ "type": "Workshop",
+ "expertise": "Beginner",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Federated AI",
- "Smart Contracts",
- "Transparency"
+ "Vyper",
+ "Solidity"
],
"tags": [
- "transparency"
+ "Tooling",
+ "DevEx",
+ "Open Source Software",
+ "solidity",
+ "DevEx",
+ "Open Source Software",
+ "Tooling"
],
"language": "en",
"speakers": [
- "sudhir-upadhyay"
+ "marc-garreau"
],
"eventId": "devcon-7",
- "slot_start": 1731564600000,
- "slot_end": 1731565200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1aXt8K7kJm7xJ0limjmVm0ZVioUUzgILAGxnm6NBfVoU"
+ "slot_start": 1731465900000,
+ "slot_end": 1731471300000,
+ "slot_roomId": "classroom-d",
+ "resources_presentation": "https://docs.google.com/presentation/d/1BdovxuMXRzh3v5kgPx7kmJtQ78cQ3TRzKpVqoR27GwE"
},
"vector": [
- 0,
- 0,
- 0,
0,
0,
0,
@@ -586661,9 +585435,8 @@
0,
0,
0,
- 6,
- 0,
0,
+ 6,
0,
0,
0,
@@ -586906,6 +585679,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -586914,6 +585688,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -586981,6 +585756,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -587245,6 +586021,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -587330,7 +586107,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -587449,7 +586225,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -587461,40 +586236,38 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "privacy-first-cbdcs",
- "sourceId": "TWMAWN",
- "title": "Privacy-First CBDCs",
- "description": "This talk explores how central bank digital currencies (CBDCs) can leverage zero-knowledge proofs (ZKPs) and Ethereum to create privacy-centric monetary systems. We'll examine how ZKPs enable robust AML/CTF compliance while preserving user privacy, discuss the benefits of Ethereum deployment for financial inclusion and innovation, and showcase how these technologies could revolutionize digital currency design. Future CBDCs can and should offer unparalleled privacy, security, and functionality.",
- "track": "Real World Ethereum",
- "type": "Talk",
+ "id": "product-led-blockchain-development",
+ "sourceId": "8YS9LW",
+ "title": "Product-Led Blockchain Development",
+ "description": "As teams spin up new app-specific rollups and L2s, we've moved into an era of product-led blockchain development. In this model, developers are not only building the first product or client to leverage their protocol, but establishing what ‘product-defined blockspace’ means. \r\n\r\nIn this talk, I go over the history of product-led growth, how it evolved to product-led protocol development in web3, and finally, what product-led blockchain development means in the context of app-specific rollups.",
+ "track": "Usability",
+ "type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Lobby",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
"keywords": [
- "CBDC"
+ "usability",
+ "product development"
],
"tags": [
- "Payment",
- "Privacy",
- "Zero-Knowledge"
+ "development",
+ "product"
],
"language": "en",
"speakers": [
- "joe-andrews",
- "andre-omietanski"
+ "gregory-rocco"
],
"eventId": "devcon-7",
- "slot_start": 1731400200000,
- "slot_end": 1731402000000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1yAUh-BkJ1oE5n2L_-NknKAtAJ9okKkjhrA-_VvME4rw"
+ "slot_start": 1731552900000,
+ "slot_end": 1731553500000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1aMtbpw97Q1DjqYA3pKLPTVpJ9vWOJoduN-rGCXYlHck"
},
"vector": [
0,
@@ -587503,10 +586276,9 @@
0,
0,
0,
- 6,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -587721,7 +586493,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -588261,19 +587032,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -588365,10 +587123,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -588390,9 +587144,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -588538,6 +587289,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -588663,6 +587415,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -588812,7 +587565,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -588827,70 +587579,61 @@
0,
0,
0,
- 2
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0
]
},
{
"session": {
- "id": "privacy-preserving-groups",
- "sourceId": "LSA3JK",
- "title": "Privacy-Preserving Groups",
- "description": "This talk will explore the concept of privacy-preserving groups and the challenges associated with managing them. It will cover different ideas to add anti-sybil mechanisms to enhance group security and trust. The presentation will also highlight real-world projects working on it and provide practical use cases to illustrate their application and impact.",
- "track": "Applied Cryptography",
+ "id": "programmable-cryptography-and-dacc",
+ "sourceId": "PNA8NU",
+ "title": "Programmable Cryptography and d/acc",
+ "description": "This short panel will explore the role of advanced programmable cryptography, beyond ZK and MPC, in d/acc. Programmable cryptographic primitives like functional encryption (FE), witness encryption (WE), and indistinguishability obfuscation (iO) have become theoretically feasible and even moving towards real-world practicality. This panel will explore how these primitives can be used to improve trust-minimized infrastructure and applications.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Tooling",
- "DAO",
- "Privacy",
- "Anonymity",
- "Identity",
- "Open Source Software",
- "ZKP",
- "Zero-Knowledge",
- "Use cases of cryptography",
- "Public good",
- "User Experience",
- "groups",
- "Anonymity",
- "DAO",
- "Identity",
- "Open Source Software",
- "Privacy",
- "Public good",
- "Tooling",
- "Use cases of cryptography",
- "User Experience",
- "Zero-Knowledge",
- "ZKP"
- ],
"keywords": [
- "Groups"
+ "d/acc",
+ "programmable cryptography"
+ ],
+ "tags": [
+ "Cryptography",
+ "Use cases of cryptography"
],
- "duration": 464,
"language": "en",
- "sources_swarmHash": "18b4db550bcad65fa27ad24340bd8c75da7a5d04c9944d8303de3e690ebbdaf8",
- "sources_youtubeId": "dWQWoqJVfn8",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330caf3a168eb535f0cb29.vtt",
- "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the theorem foundation and today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Attestation service, CKE, MelTLS, Notary, and POP. So some projects can be useful for privacy-preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-CV2. So the three main ideas from this presentation that I would like you to remember are privacy preserving groups can ideas from this presentation that I would like you to remember are like privacy preserving groups can be used to verify credentials and to have a better user experience in your applications also that you can combine different anti-civil mechanisms to have a stronger one and that's a very important is maybe it's not your case but for your, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. This works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes, Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this, the commitment to a Bandala group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with, yeah, the members in your group any other questions it's over there I see some people wearing the mere cat hat but unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, and there might be a reason to remove someone forcefully, are there any practical way to do that? Yeah, yeah, there is. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is a way, an easy way, if you are using code or not. Can you explain the mechanic behind, like how can you maintain privacy of everyone, and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean the person, it's a commitment so people don't know like who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and the admin can remove people see ya",
- "eventId": "devcon-7",
- "slot_start": 1731396600000,
- "slot_end": 1731397200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/13v7xDojqK_R5sq5GZJLvGNitJNJ0JqrztXhZYzs0pXM",
- "resources_slides": null,
"speakers": [
- "vivian-plasencia"
- ]
+ "wei-dai",
+ "muthu-venkitasubramaniam"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731578400000,
+ "slot_end": 1731579600000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1NOKA9WOe3iWdApB0QmpWreDTMUpsQvJeG7afyjEMBSQ"
},
"vector": [
0,
+ 6,
0,
0,
0,
@@ -588900,7 +587643,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -589311,6 +588053,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -589418,10 +588161,10 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -589651,26 +588394,23 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
- 6,
0,
0,
0,
0,
- 2,
0,
0,
0,
0,
2,
0,
- 2,
0,
0,
0,
@@ -589691,7 +588431,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -589717,7 +588456,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -589740,10 +588478,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -589751,14 +588487,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -590089,7 +588823,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -590205,13 +588938,19 @@
0,
0,
0,
- 2,
+ 0,
+ 0,
+ 0,
0,
2,
0,
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -590225,46 +588964,44 @@
},
{
"session": {
- "id": "prize-worthy-an-ethereum-python-hackathon-guide",
- "sourceId": "73J9ZG",
- "title": "Prize-Worthy: An Ethereum Python Hackathon Guide",
- "description": "An interactive and beginner-friendly Ethereum Python Speedrun tailored for hackathons, hosted by the EF Python team. Quickly get up to speed with fundamental building blocks, then stack them into a live application. By the end of this workshop, you'll have a clear idea of how to get your own projects off the ground.",
- "track": "Developer Experience",
- "type": "Workshop",
+ "id": "programmable-cryptography-and-ethereum-panel",
+ "sourceId": "MWKMBQ",
+ "title": "Programmable Cryptography and Ethereum, Panel",
+ "description": "One of the core themes of this panel is how Programmable Cryptography synergizes with Ethereum. Panelists will discuss questions such as ''Why have we not been able to do everything we've wanted with Ethereum?'' and ''Why have certain kinds of applications - from decentralized social to decentralized games to decentralized finance - not been able to reach their full potential with only consensus technology?''",
+ "track": "Applied Cryptography",
+ "type": "Panel",
"expertise": "Beginner",
- "audience": "Developer",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Vyper",
- "Solidity"
- ],
- "tags": [
- "Tooling",
- "DevEx",
- "Open Source Software",
- "solidity",
- "DevEx",
- "Open Source Software",
- "Tooling"
+ "Programmable Cryptography",
+ "ZKP",
+ "MPC",
+ "FHE",
+ "ORAM",
+ "Obfuscation",
+ "Panel",
+ "0xPARC"
],
+ "tags": [],
"language": "en",
"speakers": [
- "marc-garreau"
+ "gubsheep",
+ "albert-ni",
+ "barry-whitehat",
+ "vitalik-buterin"
],
"eventId": "devcon-7",
- "slot_start": 1731465900000,
- "slot_end": 1731471300000,
- "slot_roomId": "classroom-d",
- "resources_presentation": "https://docs.google.com/presentation/d/1BdovxuMXRzh3v5kgPx7kmJtQ78cQ3TRzKpVqoR27GwE"
+ "slot_start": 1731400200000,
+ "slot_end": 1731403800000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/17ZRAYhS4Uh4J1-UKAL-2OFQwRR2N0dQ4bBZOVPIoYQU"
},
"vector": [
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -590272,6 +589009,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -590443,11 +589181,14 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -590683,6 +589424,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -590791,7 +589533,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -591032,7 +589773,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -591041,7 +589781,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -591109,7 +589848,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -591375,7 +590113,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -591576,9 +590313,9 @@
0,
2,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -591594,40 +590331,48 @@
},
{
"session": {
- "id": "product-led-blockchain-development",
- "sourceId": "8YS9LW",
- "title": "Product-Led Blockchain Development",
- "description": "As teams spin up new app-specific rollups and L2s, we've moved into an era of product-led blockchain development. In this model, developers are not only building the first product or client to leverage their protocol, but establishing what ‘product-defined blockspace’ means. \r\n\r\nIn this talk, I go over the history of product-led growth, how it evolved to product-led protocol development in web3, and finally, what product-led blockchain development means in the context of app-specific rollups.",
- "track": "Usability",
+ "id": "programmable-cryptography-and-smart-contract",
+ "sourceId": "VJEDLX",
+ "title": "Programmable Cryptography and Smart Contract",
+ "description": "Overview\r\nIn some use cases, developers may want to execute smart contracts based on the results of FHE or MPC execution. This session will introduce several design patterns for such use cases and show how Programmable Cryptography can be applied to dApps.\r\n\r\nIn detail\r\nThe results of FHE executions are encrypted and need to be designed to be processed by smart contracts. In addition, the MPC+ZK-based method can solve the private state problem relatively easily using the conventional SNARK verifier.",
+ "track": "Developer Experience",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Product",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "usability",
- "product development"
- ],
"tags": [
- "development",
- "product"
+ "DevEx",
+ "Cryptography",
+ "MPC",
+ "programmable",
+ "DevEx",
+ "MPC"
],
- "language": "en",
- "speakers": [
- "gregory-rocco"
+ "keywords": [
+ "Programable",
+ "Cryptography"
],
+ "duration": 355,
+ "language": "en",
+ "sources_swarmHash": "17c804065df8bd60c3c0133f7d5ffdea4c30fe373f0ed0d016d0c9351279fb84",
+ "sources_youtubeId": "j9YnU1-MeiU",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343c949dbb7a90e1b18d92.vtt",
+ "transcript_text": "音楽通常のクリプトグラフィックスタッフのRCとして今回はZKPとセキュアコンピューティングを オフチェーンエクスクションに基づくスマートコントラクトを 運用する方法についてお話ししますまずはZKPとスマートコントラーって コーディハーブソリッティベイファイアーウェッチネイルと プレディアスベイファイアーコントラークそれキャンベルファイザー gkp オンチェーン トランスファーズアセットエニア次回はZKP、FHE、NPCでのコンピュータを発表します。後で話します。このセクションでは、FHEとスマートコントラクトをどうインテグレートするかについて話します。FHEの基本理由はエンクリプトエバリエーションです。エンクリプトをできる人レーションand only who can decrypt is just clientso it is difficult to integrate with smart contract by defaultif we using smart contractwe need to share the encrypted resultand also decryption key by client sidebut it does not make sense to achieve the secure computingrightおそびでクリアンサイトバーイティズノーメッセンスとアチーブさせてよかんぴょーてぃんばーさまーふぃーはばーそーしょん コンバイウェイズ jkp を mpcそば5 fhe is a カンティークリーンプルーザー fh エヴァレーションアンド b キャンベルファー8音ちゃーんアザイメーション b 4 b ジャイユーザー3 db ファイアーアンマーチケースチーズリトルビッドファーエンスコンセプト s スペインディクションキーアンシェア8ツーザーサーブパティコントラクトは何でもいいです2つのスタッフはとてもクールですがどうしてもスマートコントラクトにインテグレートしやすくなっています時間の証明とディアの問題に重ねています次のセクションはNPCとスマートコントラクトのインテグレートですNPCのコンセプトはコラボレーションを評価することです各パーティーはコンフィニシャルデータを コラボレーションを評価し結果を得るためにコンポジションを 作成しますこの時はスマートコントラクトと インテグレートを使いませんしかしこの問題を解決する方法を想像できます。例えば、ZKPやFHEと組み合わせることができます。NPCのベリファイアは、FHEのベリファイアと同じコンセプトです。NPCのエクスクをベリファイアで、Smart Contractでベリファイアを使認することで、Smart Contractを使用して、Solidity Verifierを使用します。また、コラボレーションスナックはNPCと同じように、ZKPとNPCを組み合わせます。しかし、これはコラボレーションスナックの場合は、コラボレーションナックスの サービスはコラボレーターにプログラムを生成していますユーザーはNPCにプログラムを 送ることができませんではセッションを終わりにしますオフチェーンのエクスクションや クリプトグラフィーのプログラム化クリプトグラフィーで スマートコントラクトを運用する方法を紹介します主なアイデアは ソリッドベリファイアとオンチェーンベラフィーはクールでサイリアムやブロックチェーンテクノロジーをエンパワーできることができます私は何か問題について考えていますプログラムの時間やデーラーの問題以上ですありがとうございましたありがとうございました質問は Thank you. Thank you, Shoki, for the session. Do we have questions for our speaker? No question? Oh, good. I forgot my volleyball lessons. Yeah, I wanted to understand what other implementations are there, like any use cases or example of FHE? Yeah, one of the FHE use cases is kind of evaluation of stats, like off-chain stats, like a bank account or or GPA or something like that I think next question okay next question okay all right since there's no more question I love to get some break you Okay. All right. Since there's no more questions, I'd love to give some break. You know, when the classroom is tense like this, you need to allow people to have some time. So please, you can get up.",
"eventId": "devcon-7",
- "slot_start": 1731552900000,
- "slot_end": 1731553500000,
+ "slot_start": 1731472200000,
+ "slot_end": 1731472800000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1aMtbpw97Q1DjqYA3pKLPTVpJ9vWOJoduN-rGCXYlHck"
+ "resources_presentation": "https://docs.google.com/presentation/d/1dUK2fPW4Yka7X0nBzFRlJXDKOPHcZn0iLzNpS3rUVcI",
+ "resources_slides": null,
+ "speakers": [
+ "shouki-tsuda"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -592156,26 +590901,9 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -592407,6 +591135,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -592423,6 +591152,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -592481,6 +591211,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -592646,7 +591377,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -592772,7 +591502,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -592838,6 +591567,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -592938,12 +591675,18 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
2,
0,
0,
@@ -592953,43 +591696,50 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
0
]
},
{
"session": {
- "id": "programmable-cryptography-and-dacc",
- "sourceId": "PNA8NU",
- "title": "Programmable Cryptography and d/acc",
- "description": "This short panel will explore the role of advanced programmable cryptography, beyond ZK and MPC, in d/acc. Programmable cryptographic primitives like functional encryption (FE), witness encryption (WE), and indistinguishability obfuscation (iO) have become theoretically feasible and even moving towards real-world practicality. This panel will explore how these primitives can be used to improve trust-minimized infrastructure and applications.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
+ "id": "programmable-cryptography-and-the-future-of-the-internet",
+ "sourceId": "JVGEDS",
+ "title": "Programmable Cryptography and the future of the Internet",
+ "description": "You rarely hear of issues at the networking layer of the Internet: networking companies are running utilities business: they are fungible and can be swapped if distrusted.\r\nMost of the value captured on the Internet -- and also most abuse -- happen at the Compute and Data layer of the Web. Ethereum gave us a glimpse of a fundamentally different architecture for Compute and Data than Client/Server architecture.We think the Internet is 1/3 complete, and that programmable cryptography can finish it.",
+ "track": "Applied Cryptography",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
+ "tags": [],
"keywords": [
- "d/acc",
- "programmable cryptography"
- ],
- "tags": [
- "Cryptography",
- "Use cases of cryptography"
+ "None"
],
+ "duration": 3349,
"language": "en",
- "speakers": [
- "wei-dai",
- "muthu-venkitasubramaniam"
- ],
+ "sources_swarmHash": "0fb50c195df8ce92474b5cefa3ba1a750793c1efe6f7bc27f06d16f5a2040a3c",
+ "sources_youtubeId": "",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731578400000,
- "slot_end": 1731579600000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1NOKA9WOe3iWdApB0QmpWreDTMUpsQvJeG7afyjEMBSQ"
+ "slot_start": 1731465900000,
+ "slot_end": 1731467700000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1yuek7FVsP0Ov8ZWMCbVJX0zA_KsFKhhx7JBnbKcs_qY",
+ "resources_slides": null,
+ "speakers": [
+ "justin-glibert"
+ ]
},
"vector": [
0,
- 6,
0,
0,
0,
@@ -592999,6 +591749,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -593169,6 +591920,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -593410,7 +592162,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -593522,7 +592273,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -593753,7 +592503,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -593768,7 +592517,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -594305,7 +593053,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -594318,44 +593065,42 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "programmable-cryptography-and-ethereum-panel",
- "sourceId": "MWKMBQ",
- "title": "Programmable Cryptography and Ethereum, Panel",
- "description": "One of the core themes of this panel is how Programmable Cryptography synergizes with Ethereum. Panelists will discuss questions such as ''Why have we not been able to do everything we've wanted with Ethereum?'' and ''Why have certain kinds of applications - from decentralized social to decentralized games to decentralized finance - not been able to reach their full potential with only consensus technology?''",
- "track": "Applied Cryptography",
- "type": "Panel",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "id": "programmable-cryptography-from-a-software-engineering-lens",
+ "sourceId": "SWD9LD",
+ "title": "Programmable Cryptography from a Software Engineering Lens",
+ "description": "Different cryptographic primitives have different affordances, especially when using them in practice, and especially together. In this session, we explore a new way of interacting with PCs at a software engineering level via a LISP like programming language. This language enables creating self-verifying graphs of computation.",
+ "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC",
+ "type": "Workshop",
+ "expertise": "Intermediate",
+ "audience": "",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Programmable Cryptography",
- "ZKP",
- "MPC",
- "FHE",
- "ORAM",
- "Obfuscation",
- "Panel",
- "0xPARC"
+ "Programmable",
+ "Cryptography"
+ ],
+ "tags": [
+ "Cryptography"
],
- "tags": [],
"language": "en",
"speakers": [
- "gubsheep",
- "albert-ni",
- "barry-whitehat",
- "vitalik-buterin"
+ "aayush-gupta",
+ "justin-glibert",
+ "arnaucube",
+ "ahmad",
+ "kevin-kwok"
],
"eventId": "devcon-7",
- "slot_start": 1731400200000,
- "slot_end": 1731403800000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/17ZRAYhS4Uh4J1-UKAL-2OFQwRR2N0dQ4bBZOVPIoYQU"
+ "slot_start": 1731648600000,
+ "slot_end": 1731654000000,
+ "slot_roomId": "breakout-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1yWVJ6yTEFsI9WxcM3wmAe6YClRLfYGGhGBGYB8pv2Sg"
},
"vector": [
0,
@@ -594368,15 +593113,11 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -594385,6 +593126,7 @@
0,
0,
0,
+ 4,
0,
0,
0,
@@ -594475,6 +593217,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -594547,9 +593290,6 @@
0,
0,
0,
- 6,
- 6,
- 0,
0,
0,
0,
@@ -594626,6 +593366,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -594784,7 +593525,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -594894,6 +593634,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -595124,6 +593865,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -595671,11 +594413,10 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
@@ -595686,6 +594427,7 @@
0,
0,
0,
+ 2,
0,
0,
0
@@ -595693,53 +594435,32 @@
},
{
"session": {
- "id": "programmable-cryptography-and-smart-contract",
- "sourceId": "VJEDLX",
- "title": "Programmable Cryptography and Smart Contract",
- "description": "Overview\r\nIn some use cases, developers may want to execute smart contracts based on the results of FHE or MPC execution. This session will introduce several design patterns for such use cases and show how Programmable Cryptography can be applied to dApps.\r\n\r\nIn detail\r\nThe results of FHE executions are encrypted and need to be designed to be processed by smart contracts. In addition, the MPC+ZK-based method can solve the private state problem relatively easily using the conventional SNARK verifier.",
- "track": "Developer Experience",
+ "id": "project-mirage-mud-day-demo",
+ "sourceId": "BVANRC",
+ "title": "Project Mirage - MUD Day Demo",
+ "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications. Project Mirage is an onchain island management game where players build, expand and trade their islands.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
"type": "Lightning Talk",
- "expertise": "Beginner",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "DevEx",
- "Cryptography",
- "MPC",
- "programmable",
- "DevEx",
- "MPC"
- ],
- "keywords": [
- "Programable",
- "Cryptography"
- ],
- "duration": 355,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "17c804065df8bd60c3c0133f7d5ffdea4c30fe373f0ed0d016d0c9351279fb84",
- "sources_youtubeId": "j9YnU1-MeiU",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343c949dbb7a90e1b18d92.vtt",
- "transcript_text": "音楽通常のクリプトグラフィックスタッフのRCとして今回はZKPとセキュアコンピューティングを オフチェーンエクスクションに基づくスマートコントラクトを 運用する方法についてお話ししますまずはZKPとスマートコントラーって コーディハーブソリッティベイファイアーウェッチネイルと プレディアスベイファイアーコントラークそれキャンベルファイザー gkp オンチェーン トランスファーズアセットエニア次回はZKP、FHE、NPCでのコンピュータを発表します。後で話します。このセクションでは、FHEとスマートコントラクトをどうインテグレートするかについて話します。FHEの基本理由はエンクリプトエバリエーションです。エンクリプトをできる人レーションand only who can decrypt is just clientso it is difficult to integrate with smart contract by defaultif we using smart contractwe need to share the encrypted resultand also decryption key by client sidebut it does not make sense to achieve the secure computingrightおそびでクリアンサイトバーイティズノーメッセンスとアチーブさせてよかんぴょーてぃんばーさまーふぃーはばーそーしょん コンバイウェイズ jkp を mpcそば5 fhe is a カンティークリーンプルーザー fh エヴァレーションアンド b キャンベルファー8音ちゃーんアザイメーション b 4 b ジャイユーザー3 db ファイアーアンマーチケースチーズリトルビッドファーエンスコンセプト s スペインディクションキーアンシェア8ツーザーサーブパティコントラクトは何でもいいです2つのスタッフはとてもクールですがどうしてもスマートコントラクトにインテグレートしやすくなっています時間の証明とディアの問題に重ねています次のセクションはNPCとスマートコントラクトのインテグレートですNPCのコンセプトはコラボレーションを評価することです各パーティーはコンフィニシャルデータを コラボレーションを評価し結果を得るためにコンポジションを 作成しますこの時はスマートコントラクトと インテグレートを使いませんしかしこの問題を解決する方法を想像できます。例えば、ZKPやFHEと組み合わせることができます。NPCのベリファイアは、FHEのベリファイアと同じコンセプトです。NPCのエクスクをベリファイアで、Smart Contractでベリファイアを使認することで、Smart Contractを使用して、Solidity Verifierを使用します。また、コラボレーションスナックはNPCと同じように、ZKPとNPCを組み合わせます。しかし、これはコラボレーションスナックの場合は、コラボレーションナックスの サービスはコラボレーターにプログラムを生成していますユーザーはNPCにプログラムを 送ることができませんではセッションを終わりにしますオフチェーンのエクスクションや クリプトグラフィーのプログラム化クリプトグラフィーで スマートコントラクトを運用する方法を紹介します主なアイデアは ソリッドベリファイアとオンチェーンベラフィーはクールでサイリアムやブロックチェーンテクノロジーをエンパワーできることができます私は何か問題について考えていますプログラムの時間やデーラーの問題以上ですありがとうございましたありがとうございました質問は Thank you. Thank you, Shoki, for the session. Do we have questions for our speaker? No question? Oh, good. I forgot my volleyball lessons. Yeah, I wanted to understand what other implementations are there, like any use cases or example of FHE? Yeah, one of the FHE use cases is kind of evaluation of stats, like off-chain stats, like a bank account or or GPA or something like that I think next question okay next question okay all right since there's no more question I love to get some break you Okay. All right. Since there's no more questions, I'd love to give some break. You know, when the classroom is tense like this, you need to allow people to have some time. So please, you can get up.",
- "eventId": "devcon-7",
- "slot_start": 1731472200000,
- "slot_end": 1731472800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1dUK2fPW4Yka7X0nBzFRlJXDKOPHcZn0iLzNpS3rUVcI",
- "resources_slides": null,
"speakers": [
- "shouki-tsuda"
- ]
+ "y77cao"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731557400000,
+ "slot_end": 1731557700000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1d-1krZg7I-YltJPVKWhfg0Tl6wSDlA4A7_wN3qi3s3M"
},
"vector": [
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -595749,6 +594470,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -596082,6 +594804,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -596270,7 +594993,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -596500,7 +595222,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -596517,7 +595238,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -596576,7 +595296,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -596935,7 +595654,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -597052,6 +595770,8 @@
0,
2,
0,
+ 0,
+ 0,
2,
0,
0,
@@ -597070,41 +595790,35 @@
},
{
"session": {
- "id": "programmable-cryptography-and-the-future-of-the-internet",
- "sourceId": "JVGEDS",
- "title": "Programmable Cryptography and the future of the Internet",
- "description": "You rarely hear of issues at the networking layer of the Internet: networking companies are running utilities business: they are fungible and can be swapped if distrusted.\r\nMost of the value captured on the Internet -- and also most abuse -- happen at the Compute and Data layer of the Web. Ethereum gave us a glimpse of a fundamentally different architecture for Compute and Data than Client/Server architecture.We think the Internet is 1/3 complete, and that programmable cryptography can finish it.",
- "track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Intermediate",
+ "id": "proof-of-personhood-panel",
+ "sourceId": "GVML7H",
+ "title": "Proof of personhood panel",
+ "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
+ "keywords": [],
"tags": [],
- "keywords": [
- "None"
- ],
- "duration": 3349,
"language": "en",
- "sources_swarmHash": "0fb50c195df8ce92474b5cefa3ba1a750793c1efe6f7bc27f06d16f5a2040a3c",
- "sources_youtubeId": "",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731465900000,
- "slot_end": 1731467700000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1yuek7FVsP0Ov8ZWMCbVJX0zA_KsFKhhx7JBnbKcs_qY",
- "resources_slides": null,
"speakers": [
- "justin-glibert"
- ]
+ "vitalik-buterin",
+ "remco-bloeman",
+ "martin-k",
+ "lasha",
+ "puja"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731559800000,
+ "slot_end": 1731561000000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1jVtcSZgrBxcYG4lFAatpVuooVRxzUpgPKggpcsgETVM"
},
"vector": [
0,
+ 6,
0,
0,
0,
@@ -597114,10 +595828,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -597286,10 +595996,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -597300,6 +596006,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -597450,6 +596157,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -597629,6 +596337,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -597640,6 +596349,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -598420,7 +597131,6 @@
2,
0,
0,
- 0,
2,
0,
0,
@@ -598439,42 +597149,45 @@
},
{
"session": {
- "id": "programmable-cryptography-from-a-software-engineering-lens",
- "sourceId": "SWD9LD",
- "title": "Programmable Cryptography from a Software Engineering Lens",
- "description": "Different cryptographic primitives have different affordances, especially when using them in practice, and especially together. In this session, we explore a new way of interacting with PCs at a software engineering level via a LISP like programming language. This language enables creating self-verifying graphs of computation.",
- "track": "[CLS] Programmable / Frogrammable Cryptography, by 0xPARC",
- "type": "Workshop",
+ "id": "protec-and-attac-programmatic-execution-layer-consensus-tests",
+ "sourceId": "GZBP8A",
+ "title": "Protec and Attac: Programmatic Execution Layer Consensus Tests",
+ "description": "We'll give an overview of Ethereum Execution Spec Tests (EEST), the new Python framework used since Shanghai to generate test vectors for Ethereum Virtual Machine (EVM) implementations. By generating tests programmatically this modular framework allows test cases to be readily parametrized and dynamically executed against clients on live networks. It tightly integrates with the Ethereum Execution Layer Specification (EELS) and could potentially be used across the L2 EVM ecosystem.",
+ "track": "Core Protocol",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Programmable",
- "Cryptography"
+ "Python",
+ "pytest"
],
"tags": [
- "Cryptography"
+ "Core Protocol",
+ "EVM-equivalent",
+ "Testing",
+ "pytest",
+ "Core Protocol",
+ "EVM-equivalent",
+ "Testing"
],
"language": "en",
"speakers": [
- "aayush-gupta",
- "justin-glibert",
- "arnaucube",
- "ahmad",
- "kevin-kwok"
+ "danceratopz"
],
"eventId": "devcon-7",
- "slot_start": 1731648600000,
- "slot_end": 1731654000000,
- "slot_roomId": "breakout-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1yWVJ6yTEFsI9WxcM3wmAe6YClRLfYGGhGBGYB8pv2Sg"
+ "slot_start": 1731483000000,
+ "slot_end": 1731484800000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1H_C3_bcxmpSTe9V9Z7CXA4jdQBIVdf6U0HYmPOFadS0"
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -598485,16 +597198,12 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
0,
0,
0,
- 4,
0,
0,
0,
@@ -598586,7 +597295,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -598653,7 +597361,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -598735,7 +597442,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -598885,6 +597591,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -599007,7 +597714,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -599236,7 +597942,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -599246,6 +597951,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -599466,6 +598172,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -599548,6 +598255,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -599603,6 +598311,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -599788,6 +598497,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -599798,7 +598508,6 @@
0,
0,
0,
- 2,
0,
0,
0
@@ -599806,27 +598515,36 @@
},
{
"session": {
- "id": "project-mirage-mud-day-demo",
- "sourceId": "BVANRC",
- "title": "Project Mirage - MUD Day Demo",
- "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications. Project Mirage is an onchain island management game where players build, expand and trade their islands.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "id": "protocol-alignment-governing-like-a-protocol",
+ "sourceId": "JDKAJD",
+ "title": "Protocol Alignment: Governing like a Protocol",
+ "description": "We define a protocol as aligned when all stakeholders in its network agree:\r\n1. The protocol’s objectives\r\n2. How to measure progress toward objectives\r\n3. How to achieve the objectives\r\n\r\nIn this talk, we'll explore both new and old decentralized mechanisms that governance leads and protocol designers can leverage to address misalignment in governance.",
+ "track": "Coordination",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "n/a"
+ ],
+ "tags": [
+ "Governance",
+ "Futarchy",
+ "Mechanism design",
+ "Futarchy",
+ "Governance",
+ "Mechanism design"
+ ],
"language": "en",
"speakers": [
- "y77cao"
+ "noturhandle"
],
"eventId": "devcon-7",
- "slot_start": 1731557400000,
- "slot_end": 1731557700000,
+ "slot_start": 1731490200000,
+ "slot_end": 1731490800000,
"slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1d-1krZg7I-YltJPVKWhfg0Tl6wSDlA4A7_wN3qi3s3M"
+ "resources_presentation": "https://docs.google.com/presentation/d/1n1_ahUlOLb7iuUb9uaTE_CyPbh0s7FZKpQGTyQ4xxps"
},
"vector": [
0,
@@ -599840,7 +598558,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -600176,10 +598893,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -600368,6 +599081,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -600589,6 +599303,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -600614,6 +599329,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -600676,6 +599392,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -601145,7 +599862,6 @@
2,
0,
0,
- 0,
2,
0,
0,
@@ -601158,44 +599874,48 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "proof-of-personhood-panel",
- "sourceId": "GVML7H",
- "title": "Proof of personhood panel",
- "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "",
- "audience": "Engineering",
+ "id": "protocol-guild-a-commons-funding-protocol",
+ "sourceId": "EJVT7E",
+ "title": "Protocol Guild: A commons funding protocol",
+ "description": "Ethereum produces two shared commons resources: a blockchain network + its underlying software. These resources are inherently un-ownable, so actors will try to capture their production processes.\r\n\r\nProtocol Guild is a compelling funding protocol. Its membership is holistic, self-curated, accessible, self-governed. The mechanism adds certainty and agency into the stewardship funding process, and gives tools to defend against capture.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "ACD",
+ "Core Protocol",
+ "DAO",
+ "Onchain Organization",
+ "Game Theory"
+ ],
+ "tags": [
+ "Gaming",
+ "theory"
+ ],
"language": "en",
"speakers": [
- "vitalik-buterin",
- "remco-bloeman",
- "martin-k",
- "lasha",
- "puja"
+ "trent-van-epps"
],
"eventId": "devcon-7",
- "slot_start": 1731559800000,
- "slot_end": 1731561000000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1jVtcSZgrBxcYG4lFAatpVuooVRxzUpgPKggpcsgETVM"
+ "slot_start": 1731646800000,
+ "slot_end": 1731648600000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1X-IkjzbaZoye8kj19czZe1suKsBA9C7jL4gsmxYI5ko"
},
"vector": [
0,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -601381,7 +600101,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -601532,7 +600251,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -601716,7 +600434,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -601728,9 +600445,8 @@
0,
0,
0,
- 6,
- 6,
0,
+ 6,
0,
0,
0,
@@ -602055,6 +600771,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -602389,6 +601106,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -602508,12 +601226,11 @@
2,
0,
0,
- 2,
- 0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -602526,47 +601243,42 @@
},
{
"session": {
- "id": "protec-and-attac-programmatic-execution-layer-consensus-tests",
- "sourceId": "GZBP8A",
- "title": "Protec and Attac: Programmatic Execution Layer Consensus Tests",
- "description": "We'll give an overview of Ethereum Execution Spec Tests (EEST), the new Python framework used since Shanghai to generate test vectors for Ethereum Virtual Machine (EVM) implementations. By generating tests programmatically this modular framework allows test cases to be readily parametrized and dynamically executed against clients on live networks. It tightly integrates with the Ethereum Execution Layer Specification (EELS) and could potentially be used across the L2 EVM ecosystem.",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "proving-liquidity-of-an-amm",
+ "sourceId": "AD3X38",
+ "title": "Proving liquidity of an AMM",
+ "description": "Liquidity providers in an AMM expect that they can always withdraw their tokens, even in case of a bank run. Taking the concrete implementation of Uniswap v4, we formally proved that the funds owned by the contract always cover the provided liquidity. This talk describes the methodology for proving this critical property, which can be applied to other protocols holding the liquidity for their users.",
+ "track": "Security",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Python",
- "pytest"
+ "Invariants"
],
"tags": [
- "Core Protocol",
- "EVM-equivalent",
- "Testing",
- "pytest",
- "Core Protocol",
- "EVM-equivalent",
- "Testing"
+ "Formal Verification",
+ "Reentrancy",
+ "invariants",
+ "Formal Verification",
+ "Reentrancy"
],
"language": "en",
"speakers": [
- "danceratopz"
+ "jochen-hoenicke"
],
"eventId": "devcon-7",
- "slot_start": 1731483000000,
- "slot_end": 1731484800000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1H_C3_bcxmpSTe9V9Z7CXA4jdQBIVdf6U0HYmPOFadS0"
+ "slot_start": 1731471000000,
+ "slot_end": 1731471600000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1QlA6rBFr3f12d9BFrh9CBVqTCO60FFqlit1W076MzQ8"
},
"vector": [
+ 6,
0,
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -602969,7 +601681,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -603099,6 +601810,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -603331,7 +602043,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -603509,6 +602220,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -603553,7 +602265,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -603636,7 +602347,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -603692,7 +602402,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -603761,6 +602470,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -603877,9 +602588,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -603895,38 +602606,35 @@
},
{
"session": {
- "id": "protocol-alignment-governing-like-a-protocol",
- "sourceId": "JDKAJD",
- "title": "Protocol Alignment: Governing like a Protocol",
- "description": "We define a protocol as aligned when all stakeholders in its network agree:\r\n1. The protocol’s objectives\r\n2. How to measure progress toward objectives\r\n3. How to achieve the objectives\r\n\r\nIn this talk, we'll explore both new and old decentralized mechanisms that governance leads and protocol designers can leverage to address misalignment in governance.",
- "track": "Coordination",
+ "id": "public-epistemics-and-futarchy",
+ "sourceId": "3UX8GZ",
+ "title": "Public epistemics and futarchy",
+ "description": "35 years ago I began outlining a vision of how betting markets could offer informed credibly-neutral estimates on far more disputed topics. I elaborated 25 years ago on how decision markets could support neutral governance, and 21 years ago on how combinatorial markets allow estimates on all possible combinations for existing topics. Now in the last year, we are seeing substantial crypto-based trials, especially re governance. In this talk, I’ll paint a picture of where all this could go.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Research",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "n/a"
- ],
+ "keywords": [],
"tags": [
- "Governance",
- "Futarchy",
- "Mechanism design",
- "Futarchy",
- "Governance",
- "Mechanism design"
+ "Economics",
+ "Free Speech",
+ "Futarchy"
],
"language": "en",
"speakers": [
- "noturhandle"
+ "robin-hanson"
],
"eventId": "devcon-7",
- "slot_start": 1731490200000,
- "slot_end": 1731490800000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1n1_ahUlOLb7iuUb9uaTE_CyPbh0s7FZKpQGTyQ4xxps"
+ "slot_start": 1731562200000,
+ "slot_end": 1731563100000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1P1IH_O2NLxK_MXtmkfR8Yb6EoLR6gV1arcuKrkGimqE"
},
"vector": [
+ 0,
+ 6,
0,
0,
0,
@@ -603938,7 +602646,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -604133,6 +602840,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -604466,7 +603174,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -604686,11 +603393,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -604707,6 +603409,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -604714,6 +603417,7 @@
0,
2,
0,
+ 2,
0,
0,
0,
@@ -604775,7 +603479,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -605245,11 +603948,11 @@
2,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -605262,49 +603965,58 @@
},
{
"session": {
- "id": "protocol-guild-a-commons-funding-protocol",
- "sourceId": "EJVT7E",
- "title": "Protocol Guild: A commons funding protocol",
- "description": "Ethereum produces two shared commons resources: a blockchain network + its underlying software. These resources are inherently un-ownable, so actors will try to capture their production processes.\r\n\r\nProtocol Guild is a compelling funding protocol. Its membership is holistic, self-curated, accessible, self-governed. The mechanism adds certainty and agency into the stewardship funding process, and gives tools to defend against capture.",
- "track": "Core Protocol",
+ "id": "public-private-hybrid-rollups",
+ "sourceId": "YUFEJK",
+ "title": "Public-Private Hybrid Rollups",
+ "description": "We posit that it is a best practice that rollups have privacy capabilities. We'll focus on zero-knowledge and its role in enhancing privacy and how to deal with the need for public state for shared use cases. We'll delve into the interaction between public and private execution environments, detailing how such disparate execution environments can be combined.",
+ "track": "Layer 2",
"type": "Talk",
- "expertise": "Beginner",
- "audience": "Community",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "ACD",
- "Core Protocol",
- "DAO",
- "Onchain Organization",
- "Game Theory"
- ],
"tags": [
- "Gaming",
- "theory"
+ "Zk Rollups",
+ "Token bridging",
+ "Privacy",
+ "best",
+ "practice",
+ "Privacy",
+ "Token bridging",
+ "Zk Rollups"
],
- "language": "en",
- "speakers": [
- "trent-van-epps"
+ "keywords": [
+ "hybrid rollups",
+ "privacy as a best practice"
],
+ "duration": 1396,
+ "language": "en",
+ "sources_swarmHash": "2e6b811ad2567c4e1aca22ebd687a47279b5f1ce00313a27a958d3092402370e",
+ "sources_youtubeId": "0mDlVkzde_M",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731646800000,
- "slot_end": 1731648600000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1X-IkjzbaZoye8kj19czZe1suKsBA9C7jL4gsmxYI5ko"
+ "slot_start": 1731400200000,
+ "slot_end": 1731402000000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/11nsntpn_PkweY9PIGZYHntFGei0Pk5LLe9J12awK9K4",
+ "resources_slides": null,
+ "speakers": [
+ "adam-domurad"
+ ]
},
"vector": [
0,
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -606115,6 +604827,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -606157,13 +604870,11 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -606250,6 +604961,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -606607,16 +605319,16 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -606629,42 +605341,38 @@
},
{
"session": {
- "id": "proving-liquidity-of-an-amm",
- "sourceId": "AD3X38",
- "title": "Proving liquidity of an AMM",
- "description": "Liquidity providers in an AMM expect that they can always withdraw their tokens, even in case of a bank run. Taking the concrete implementation of Uniswap v4, we formally proved that the funds owned by the contract always cover the provided liquidity. This talk describes the methodology for proving this critical property, which can be applied to other protocols holding the liquidity for their users.",
- "track": "Security",
+ "id": "putting-identities-on-chain-passport-zkp",
+ "sourceId": "HBH3Y7",
+ "title": "Putting Identities On-Chain (Passport ZKP)",
+ "description": "Discussing the creation of an on-chain registry system for storing zero-knowledge (zk) identities. This system will enable individuals to self-issue and control their data without a central authority, showcasing the ZK passport use case.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Invariants"
+ "ZK passport",
+ "social graph"
],
"tags": [
- "Formal Verification",
- "Reentrancy",
- "invariants",
- "Formal Verification",
- "Reentrancy"
+ "Digital Sovereignty",
+ "Identity",
+ "Permissionless"
],
"language": "en",
"speakers": [
- "jochen-hoenicke"
+ "lasha"
],
"eventId": "devcon-7",
- "slot_start": 1731471000000,
- "slot_end": 1731471600000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1QlA6rBFr3f12d9BFrh9CBVqTCO60FFqlit1W076MzQ8"
+ "slot_start": 1731559320000,
+ "slot_end": 1731559800000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1zX7rgpH4mVoH4btzraVJBbogPvAVttN57Twcs55Kb2I"
},
"vector": [
- 6,
- 0,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -607195,13 +605903,13 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -607461,6 +606169,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -607609,7 +606319,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -607675,6 +606384,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -607862,8 +606572,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -607977,9 +606685,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -607995,38 +606703,41 @@
},
{
"session": {
- "id": "public-epistemics-and-futarchy",
- "sourceId": "3UX8GZ",
- "title": "Public epistemics and futarchy",
- "description": "35 years ago I began outlining a vision of how betting markets could offer informed credibly-neutral estimates on far more disputed topics. I elaborated 25 years ago on how decision markets could support neutral governance, and 21 years ago on how combinatorial markets allow estimates on all possible combinations for existing topics. Now in the last year, we are seeing substantial crypto-based trials, especially re governance. In this talk, I’ll paint a picture of where all this could go.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "id": "putting-intents-and-users-together",
+ "sourceId": "YUPJGZ",
+ "title": "Putting Intents and Users Together",
+ "description": "Intents represent a new approach to Web3 interactions. However, the transition from the existing structure to an intent-centric space remains uncertain unless we maintain user familiarity. We conducted experiments on user experience for intents and tested them with a focus group. This talk will explore how we can approach intents in a way that users will adopt more readily by leveraging the latest standards and EIPs, including EIP-7702, ERC-4337, ERC-7579, and ERC-7715.",
+ "track": "Usability",
"type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Community",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
+ "keywords": [
+ "Chain",
+ "Abstraction"
+ ],
"tags": [
- "Economics",
- "Free Speech",
- "Futarchy"
+ "Rollups",
+ "Account Abstraction",
+ "Intents",
+ "chain",
+ "abstraction",
+ "Account Abstraction",
+ "Intents",
+ "Rollups"
],
"language": "en",
"speakers": [
- "robin-hanson"
+ "abhimanyu-shekhawat"
],
"eventId": "devcon-7",
- "slot_start": 1731562200000,
- "slot_end": 1731563100000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1P1IH_O2NLxK_MXtmkfR8Yb6EoLR6gV1arcuKrkGimqE"
+ "slot_start": 1731557400000,
+ "slot_end": 1731558000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1oa41JFQPp-vuRePzM4jYH0K22uvY02iOso74y9q_Ryc"
},
"vector": [
- 0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -608035,6 +606746,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -608284,7 +606996,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -608565,6 +607276,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -608801,15 +607513,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
@@ -608820,6 +607529,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -608828,9 +607538,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -608976,6 +607688,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -609334,6 +608048,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -609344,8 +608059,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -609357,48 +608070,42 @@
},
{
"session": {
- "id": "public-private-hybrid-rollups",
- "sourceId": "YUFEJK",
- "title": "Public-Private Hybrid Rollups",
- "description": "We posit that it is a best practice that rollups have privacy capabilities. We'll focus on zero-knowledge and its role in enhancing privacy and how to deal with the need for public state for shared use cases. We'll delve into the interaction between public and private execution environments, detailing how such disparate execution environments can be combined.",
- "track": "Layer 2",
+ "id": "quarkid-bringing-south-america-on-chain-with-ssi-and-account-abstraction",
+ "sourceId": "QXCTMB",
+ "title": "QuarkID: Bringing South America on-chain with SSI and account Abstraction",
+ "description": "QuarkID is a Self-Sovereign Identity protocol bringing millions of South American citizens on-chain. Citizens in Buenos Aires, Argentina, Monterrey, and Nuevo Leon, Mexico, are using government SSI deployed on ZKsync Era through the QuarkID protocol. Driver's licenses, birth certificates, and over 50 different credentials are secured by Ethereum technology in the world’s first case of governments using Ethereum’s permissionless blockchain to meet their identity needs.",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Zk Rollups",
- "Token bridging",
- "Privacy",
- "best",
- "practice",
- "Privacy",
- "Token bridging",
- "Zk Rollups"
- ],
"keywords": [
- "hybrid rollups",
- "privacy as a best practice"
+ "Sovereign"
+ ],
+ "tags": [
+ "2FA",
+ "Account Abstraction",
+ "Identity",
+ "Open Source Software",
+ "Political systems",
+ "Politics",
+ "Public good",
+ "Use Cases",
+ "Validiums",
+ "Zero-Knowledge",
+ "ZK-EVMs",
+ "ZKP"
],
- "duration": 1396,
"language": "en",
- "sources_swarmHash": "2e6b811ad2567c4e1aca22ebd687a47279b5f1ce00313a27a958d3092402370e",
- "sources_youtubeId": "0mDlVkzde_M",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731400200000,
- "slot_end": 1731402000000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/11nsntpn_PkweY9PIGZYHntFGei0Pk5LLe9J12awK9K4",
- "resources_slides": null,
"speakers": [
- "adam-domurad"
- ]
+ "diego-fernandez"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731556800000,
+ "slot_end": 1731558600000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1nZf4Y4ZKlAYK_rEfdGkjjq6S4WGbMxpwSUXYgi9pq-M"
},
"vector": [
0,
@@ -609407,7 +608114,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -609941,8 +608647,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -610165,6 +608869,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -610201,7 +608906,9 @@
0,
0,
0,
+ 2,
0,
+ 2,
0,
0,
0,
@@ -610222,18 +608929,14 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -610252,6 +608955,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -610259,8 +608963,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -610269,7 +608975,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -610319,6 +609024,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -610356,8 +609062,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -610487,6 +609191,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -610499,6 +609204,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -610601,11 +609307,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -610718,11 +609424,9 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
+ 2,
0,
0,
0,
@@ -610736,34 +609440,27 @@
},
{
"session": {
- "id": "putting-identities-on-chain-passport-zkp",
- "sourceId": "HBH3Y7",
- "title": "Putting Identities On-Chain (Passport ZKP)",
- "description": "Discussing the creation of an on-chain registry system for storing zero-knowledge (zk) identities. This system will enable individuals to self-issue and control their data without a central authority, showcasing the ZK passport use case.",
+ "id": "reading-before-writing-an-approach-to-brain-interfaces",
+ "sourceId": "AECBRW",
+ "title": "Reading Before Writing: An Approach to Brain Interfaces",
+ "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
"track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
- "expertise": "Intermediate",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "ZK passport",
- "social graph"
- ],
- "tags": [
- "Digital Sovereignty",
- "Identity",
- "Permissionless"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
"speakers": [
- "lasha"
+ "mackenzie-dion"
],
"eventId": "devcon-7",
- "slot_start": 1731559320000,
- "slot_end": 1731559800000,
+ "slot_start": 1731557160000,
+ "slot_end": 1731557580000,
"slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1zX7rgpH4mVoH4btzraVJBbogPvAVttN57Twcs55Kb2I"
+ "resources_presentation": "https://docs.google.com/presentation/d/1yeFg5w90FisDwxUH5GvlEr2tT53GBDkWeBVcOZI2p7c"
},
"vector": [
0,
@@ -611303,10 +610000,11 @@
0,
0,
0,
- 6,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -611567,8 +610265,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -611783,7 +610479,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -612082,7 +610777,6 @@
2,
0,
0,
- 0,
2,
0,
0,
@@ -612101,45 +610795,44 @@
},
{
"session": {
- "id": "putting-intents-and-users-together",
- "sourceId": "YUPJGZ",
- "title": "Putting Intents and Users Together",
- "description": "Intents represent a new approach to Web3 interactions. However, the transition from the existing structure to an intent-centric space remains uncertain unless we maintain user familiarity. We conducted experiments on user experience for intents and tested them with a focus group. This talk will explore how we can approach intents in a way that users will adopt more readily by leveraging the latest standards and EIPs, including EIP-7702, ERC-4337, ERC-7579, and ERC-7715.",
- "track": "Usability",
- "type": "Lightning Talk",
+ "id": "reading-ethereums-tea-leaves-with-xatu-data",
+ "sourceId": "LGXA3Q",
+ "title": "Reading Ethereum's Tea Leaves with Xatu data",
+ "description": "Demonstrate how we collect data from the Ethereum network and how it's used for upgrades, research, and analytics. We'll then run through some examples of how to use the tools and public datasets yourself.",
+ "track": "Core Protocol",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Chain",
- "Abstraction"
+ "Data",
+ "Analysis",
+ "Observability"
],
"tags": [
- "Rollups",
- "Account Abstraction",
- "Intents",
- "chain",
- "abstraction",
- "Account Abstraction",
- "Intents",
- "Rollups"
+ "Layer 1",
+ "Consensus",
+ "Testing",
+ "observability",
+ "Consensus",
+ "Layer 1",
+ "Testing"
],
"language": "en",
"speakers": [
- "abhimanyu-shekhawat"
+ "toni-wahrstatter",
+ "andrew-davis",
+ "sam-calder-mason",
+ "leo-bautista-gomez"
],
"eventId": "devcon-7",
- "slot_start": 1731557400000,
- "slot_end": 1731558000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1oa41JFQPp-vuRePzM4jYH0K22uvY02iOso74y9q_Ryc"
+ "slot_start": 1731555000000,
+ "slot_end": 1731560400000,
+ "slot_roomId": "classroom-d",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Ii_t0zNEsYz1aRQml-w9fPgG3GbBAXs49o3KIFZpdCM"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -612195,6 +610888,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -612600,6 +611294,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -612680,6 +611375,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -612891,6 +611587,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -612900,6 +611597,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -612930,8 +611628,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -612939,11 +611635,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -613089,8 +611783,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -613130,6 +611822,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -613340,6 +612033,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -613453,8 +612147,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -613471,42 +612165,41 @@
},
{
"session": {
- "id": "quarkid-bringing-south-america-on-chain-with-ssi-and-account-abstraction",
- "sourceId": "QXCTMB",
- "title": "QuarkID: Bringing South America on-chain with SSI and account Abstraction",
- "description": "QuarkID is a Self-Sovereign Identity protocol bringing millions of South American citizens on-chain. Citizens in Buenos Aires, Argentina, Monterrey, and Nuevo Leon, Mexico, are using government SSI deployed on ZKsync Era through the QuarkID protocol. Driver's licenses, birth certificates, and over 50 different credentials are secured by Ethereum technology in the world’s first case of governments using Ethereum’s permissionless blockchain to meet their identity needs.",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Beginner",
+ "id": "realigning-with-ethereum-from-l1-to-l2",
+ "sourceId": "PSSQCK",
+ "title": "(Re)aligning with Ethereum: From L1 to L2",
+ "description": "In this round table, Justin Drake and Marek Olszewski will explore the rational and tangible pros and cons of (re) launching an Ethereum L2. They will explore the why and how of launching an Ethereum L2 from a technical and ecosystem perspective.",
+ "track": "Layer 2",
+ "type": "Panel",
+ "expertise": "Intermediate",
"audience": "Product",
"featured": false,
- "doNotRecord": false,
+ "doNotRecord": true,
"keywords": [
- "Sovereign"
+ "Transition",
+ "Ethereum Allignment",
+ "EVM"
],
"tags": [
- "2FA",
- "Account Abstraction",
- "Identity",
- "Open Source Software",
- "Political systems",
- "Politics",
- "Public good",
- "Use Cases",
- "Validiums",
- "Zero-Knowledge",
- "ZK-EVMs",
- "ZKP"
+ "Layer 1",
+ "Layer 2s",
+ "Values",
+ "EVM",
+ "Layer 1",
+ "Layer 2s",
+ "Values"
],
"language": "en",
"speakers": [
- "diego-fernandez"
+ "justin-drake",
+ "marek-olszewski",
+ "david-hoffman"
],
"eventId": "devcon-7",
- "slot_start": 1731556800000,
- "slot_end": 1731558600000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1nZf4Y4ZKlAYK_rEfdGkjjq6S4WGbMxpwSUXYgi9pq-M"
+ "slot_start": 1731488400000,
+ "slot_end": 1731492000000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1JF1fLnBMiSF5FSuifcPd7xXZqFJpC793NAwW7MxdqhM"
},
"vector": [
0,
@@ -613515,6 +612208,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -613940,6 +612634,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -614050,10 +612745,11 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -614270,10 +612966,10 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -614310,9 +613006,7 @@
0,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
@@ -614323,6 +613017,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -614336,11 +613031,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -614359,7 +613052,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -614367,10 +613059,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -614385,6 +613075,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -614428,7 +613119,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -614468,6 +613158,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -614596,7 +613287,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -614609,7 +613299,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -614714,7 +613403,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -614830,6 +613518,8 @@
0,
0,
0,
+ 0,
+ 0,
2,
0,
0,
@@ -614844,37 +613534,55 @@
},
{
"session": {
- "id": "reading-before-writing-an-approach-to-brain-interfaces",
- "sourceId": "AECBRW",
- "title": "Reading Before Writing: An Approach to Brain Interfaces",
- "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "",
+ "id": "realizing-the-rollup-centric-roadmap-with-rollup-boost",
+ "sourceId": "YRTHKH",
+ "title": "Realizing the Rollup Centric Roadmap with Rollup-Boost",
+ "description": "L2s are the future, but they're also the past. At this point it's clear that your phone is most likely an L6. Let's examine the feedback loops between L1, L2, and beyond and form community standards around multiprovers, distributed block building, inclusion guarantees and more that feed back into L1.",
+ "track": "Layer 2",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Preconfirmations"
+ ],
+ "tags": [
+ "Architecture",
+ "Protocol Design",
+ "Scalability",
+ "Appchains",
+ "Decentralization",
+ "User Experience",
+ "MEV",
+ "pre-confirmations",
+ "Appchains",
+ "Architecture",
+ "Decentralization",
+ "MEV",
+ "Protocol Design",
+ "Scalability",
+ "User Experience"
+ ],
"language": "en",
"speakers": [
- "mackenzie-dion"
+ "daniel-marzec"
],
"eventId": "devcon-7",
- "slot_start": 1731557160000,
- "slot_end": 1731557580000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1yeFg5w90FisDwxUH5GvlEr2tT53GBDkWeBVcOZI2p7c"
+ "slot_start": 1731479400000,
+ "slot_end": 1731481200000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1B_rCk0bkXtF-tfbBfcDeRBqZxjx4AKThyOjuNnKCVhw"
},
"vector": [
0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -615618,6 +614326,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -615631,6 +614340,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -615660,6 +614370,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -615675,6 +614386,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -615714,6 +614426,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -615724,6 +614437,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -615750,6 +614464,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -615937,18 +614652,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -616184,6 +614888,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -616202,49 +614907,43 @@
},
{
"session": {
- "id": "reading-ethereums-tea-leaves-with-xatu-data",
- "sourceId": "LGXA3Q",
- "title": "Reading Ethereum's Tea Leaves with Xatu data",
- "description": "Demonstrate how we collect data from the Ethereum network and how it's used for upgrades, research, and analytics. We'll then run through some examples of how to use the tools and public datasets yourself.",
- "track": "Core Protocol",
- "type": "Workshop",
- "expertise": "Intermediate",
+ "id": "reclaiming-our-dollar8-billion-funding-public-goods-with-stablecoin-profits",
+ "sourceId": "UCFEEN",
+ "title": "Reclaiming our $8 billion: funding public goods with stablecoin profits",
+ "description": "Ethereum is stuck in a dark deal with two companies. They control ~all stablecoins; facilitate 49% of DEX swaps; and can overrule all future hardforks:\r\n\r\nCircle & Tether.\r\n\r\nIn return, they reap $7.4B in stablecoin earnings (2023).\r\n\r\nBut wait—that’s the interest on OUR money! We should be in control.\r\n\r\nGiving to holders is illegal, but funding public goods isn’t.\r\n\r\nIf we coordinate, we can switch to nonprofit stablecoins and reclaim billions for eg Protocol Guild, R&D, DeFi infra, OSS—or other causes.",
+ "track": "Coordination",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
"audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Data",
- "Analysis",
- "Observability"
+ "Stablecoins"
],
"tags": [
- "Layer 1",
- "Consensus",
- "Testing",
- "observability",
- "Consensus",
- "Layer 1",
- "Testing"
+ "Decentralization Improvements",
+ "Censorship Resistance",
+ "Open Source Software",
+ "stablecoin",
+ "Censorship Resistance",
+ "Decentralization Improvements",
+ "Open Source Software"
],
"language": "en",
"speakers": [
- "toni-wahrstatter",
- "andrew-davis",
- "sam-calder-mason",
- "leo-bautista-gomez"
+ "garm"
],
"eventId": "devcon-7",
- "slot_start": 1731555000000,
- "slot_end": 1731560400000,
- "slot_roomId": "classroom-d",
- "resources_presentation": "https://docs.google.com/presentation/d/1Ii_t0zNEsYz1aRQml-w9fPgG3GbBAXs49o3KIFZpdCM"
+ "slot_start": 1731582000000,
+ "slot_end": 1731582600000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1AC1UEYubPRYIH9AzVy-E905hMuR67GeAMdfpHpaGm0g"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -616252,6 +614951,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -616295,7 +614995,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -616705,7 +615404,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -616786,10 +615484,9 @@
0,
0,
0,
- 6,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -616997,8 +615694,8 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -617007,7 +615704,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -617091,6 +615787,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -617140,6 +615837,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -617233,7 +615931,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -617444,9 +616141,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -617553,9 +616250,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
2,
@@ -617575,41 +616272,48 @@
},
{
"session": {
- "id": "realigning-with-ethereum-from-l1-to-l2",
- "sourceId": "PSSQCK",
- "title": "(Re)aligning with Ethereum: From L1 to L2",
- "description": "In this round table, Justin Drake and Marek Olszewski will explore the rational and tangible pros and cons of (re) launching an Ethereum L2. They will explore the why and how of launching an Ethereum L2 from a technical and ecosystem perspective.",
- "track": "Layer 2",
+ "id": "redefined-interactions-transforming-user-experience-with-intents",
+ "sourceId": "Q3SF8Q",
+ "title": "Redefined Interactions: Transforming User Experience with Intents",
+ "description": "Intents are on their way to improving users' interactions with DeFi. This panel of experts from leading protocols will discuss the impact of Intents on user experience, focusing on streamlining processes, enhancing security, increasing decentralization, and making DeFi more accessible. Explore the future of user interactions in DeFi and the collaborative efforts driving these advancements.",
+ "track": "Usability",
"type": "Panel",
"expertise": "Intermediate",
"audience": "Product",
"featured": false,
- "doNotRecord": true,
- "keywords": [
- "Transition",
- "Ethereum Allignment",
- "EVM"
- ],
+ "doNotRecord": false,
"tags": [
- "Layer 1",
- "Layer 2s",
- "Values",
- "EVM",
- "Layer 1",
- "Layer 2s",
- "Values"
+ "User Experience",
+ "Intents",
+ "defi",
+ "Intents",
+ "User Experience"
],
- "language": "en",
- "speakers": [
- "justin-drake",
- "marek-olszewski",
- "david-hoffman"
+ "keywords": [
+ "DeFi"
],
+ "duration": 2896,
+ "language": "en",
+ "sources_swarmHash": "b62c90d88cd31739d845fd3c69549705e18eb151c919421eddbcaa08ad72ab94",
+ "sources_youtubeId": "hId-FQUOpJ0",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731488400000,
- "slot_end": 1731492000000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1JF1fLnBMiSF5FSuifcPd7xXZqFJpC793NAwW7MxdqhM"
+ "slot_start": 1731406200000,
+ "slot_end": 1731409800000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1pQP77cQCgded-4Om05CtsNholtmf6N8hdDeVEVTDvKU",
+ "resources_slides": null,
+ "speakers": [
+ "agustin-grosso",
+ "juli-corti",
+ "ran-hammer",
+ "dominik-hell",
+ "shawn-odonaghue"
+ ]
},
"vector": [
0,
@@ -617619,8 +616323,8 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -618045,7 +616749,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -618162,10 +616865,9 @@
0,
6,
6,
- 0,
- 0,
- 0,
- 0,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -618418,6 +617120,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -618430,7 +617133,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -618488,7 +617190,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -618555,6 +617256,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -618571,7 +617273,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -618947,45 +617648,29 @@
},
{
"session": {
- "id": "realizing-the-rollup-centric-roadmap-with-rollup-boost",
- "sourceId": "YRTHKH",
- "title": "Realizing the Rollup Centric Roadmap with Rollup-Boost",
- "description": "L2s are the future, but they're also the past. At this point it's clear that your phone is most likely an L6. Let's examine the feedback loops between L1, L2, and beyond and form community standards around multiprovers, distributed block building, inclusion guarantees and more that feed back into L1.",
- "track": "Layer 2",
+ "id": "redefining-boundaries-in-the-infinite-garden",
+ "sourceId": "FUZDNX",
+ "title": "Redefining boundaries in the Infinite Garden",
+ "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Intermediate",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Preconfirmations"
- ],
- "tags": [
- "Architecture",
- "Protocol Design",
- "Scalability",
- "Appchains",
- "Decentralization",
- "User Experience",
- "MEV",
- "pre-confirmations",
- "Appchains",
- "Architecture",
- "Decentralization",
- "MEV",
- "Protocol Design",
- "Scalability",
- "User Experience"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
"speakers": [
- "daniel-marzec"
+ "aya-miyaguchi"
],
"eventId": "devcon-7",
- "slot_start": 1731479400000,
- "slot_end": 1731481200000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1B_rCk0bkXtF-tfbBfcDeRBqZxjx4AKThyOjuNnKCVhw"
+ "slot_start": 1731382800000,
+ "slot_end": 1731384000000,
+ "slot_roomId": "main-stage",
+ "sources_youtubeId": "SE15rsPVHz0",
+ "sources_swarmHash": "ad356189d2834782997d461c0a3e4b34ad700af2998a1d88369a28e185b406d0",
+ "resources_presentation": "https://docs.google.com/presentation/d/1K5z-RKHIToQZFNAHUKMDOmuOsAKkNs4VPNUiIqAAe9M"
},
"vector": [
0,
@@ -618994,7 +617679,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -619169,6 +617853,56 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -619538,7 +618272,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -619742,7 +618475,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -619756,7 +618488,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -619786,7 +618517,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -619802,7 +618532,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -619842,7 +618571,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -619853,7 +618581,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -619880,7 +618607,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -620069,49 +618795,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -620304,7 +618987,6 @@
2,
0,
0,
- 0,
2,
0,
0,
@@ -620323,37 +619005,51 @@
},
{
"session": {
- "id": "reclaiming-our-dollar8-billion-funding-public-goods-with-stablecoin-profits",
- "sourceId": "UCFEEN",
- "title": "Reclaiming our $8 billion: funding public goods with stablecoin profits",
- "description": "Ethereum is stuck in a dark deal with two companies. They control ~all stablecoins; facilitate 49% of DEX swaps; and can overrule all future hardforks:\r\n\r\nCircle & Tether.\r\n\r\nIn return, they reap $7.4B in stablecoin earnings (2023).\r\n\r\nBut wait—that’s the interest on OUR money! We should be in control.\r\n\r\nGiving to holders is illegal, but funding public goods isn’t.\r\n\r\nIf we coordinate, we can switch to nonprofit stablecoins and reclaim billions for eg Protocol Guild, R&D, DeFi infra, OSS—or other causes.",
+ "id": "redefining-daos-state-of-daos-in-asia",
+ "sourceId": "PUMYRH",
+ "title": "Redefining DAOs: State of DAOs in Asia",
+ "description": "We are a team from Metagov and DAOstar, advancing the global DAO movement through standards like ERC-4824 and exploring diverse DAO narratives worldwide. We've commissioned multiple reports on the “State of DAOs” in Asia, covering Japan, South Korea, Taiwan, Singapore, Greater China, and SEA. Our panel will discuss these findings, focusing on DAO narratives, regulations, opportunities, and differences between Eastern and Western DAOs, aiming to bridge the gap in the global DAO discourse.",
"track": "Coordination",
- "type": "Lightning Talk",
+ "type": "Panel",
"expertise": "Beginner",
- "audience": "Research",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Stablecoins"
- ],
"tags": [
- "Decentralization Improvements",
- "Censorship Resistance",
- "Open Source Software",
- "stablecoin",
- "Censorship Resistance",
- "Decentralization Improvements",
- "Open Source Software"
+ "Coordination",
+ "DAO",
+ "Governance",
+ "asia",
+ "Coordination",
+ "DAO",
+ "Governance"
],
- "language": "en",
- "speakers": [
- "garm"
+ "keywords": [
+ "Standards",
+ "Asia"
],
+ "duration": 3320,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "Mwui5uJ7hSI",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731582000000,
- "slot_end": 1731582600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1AC1UEYubPRYIH9AzVy-E905hMuR67GeAMdfpHpaGm0g"
+ "slot_start": 1731472200000,
+ "slot_end": 1731475800000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ieI7X9rFpOPzhR32w8gT6d_tE2y-xDKaSS2cr_K6lgE",
+ "resources_slides": null,
+ "speakers": [
+ "joseph-low",
+ "dev-lewis",
+ "hazel-devjani",
+ "gen",
+ "yvonne"
+ ]
},
"vector": [
0,
@@ -620907,12 +619603,12 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
+ 6,
+ 6,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -621114,7 +619810,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -621202,6 +619897,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -621256,14 +619952,11 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -621561,9 +620254,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -621674,11 +620367,11 @@
2,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -621691,54 +620384,40 @@
},
{
"session": {
- "id": "redefined-interactions-transforming-user-experience-with-intents",
- "sourceId": "Q3SF8Q",
- "title": "Redefined Interactions: Transforming User Experience with Intents",
- "description": "Intents are on their way to improving users' interactions with DeFi. This panel of experts from leading protocols will discuss the impact of Intents on user experience, focusing on streamlining processes, enhancing security, increasing decentralization, and making DeFi more accessible. Explore the future of user interactions in DeFi and the collaborative efforts driving these advancements.",
- "track": "Usability",
- "type": "Panel",
- "expertise": "Intermediate",
- "audience": "Product",
+ "id": "redis-evm-supercharging-ethereum-calls-with-in-memory-execution",
+ "sourceId": "FKVE9X",
+ "title": "Redis EVM: Supercharging Ethereum calls with in-memory execution",
+ "description": "Redis EVM is a research project that embeds an Ethereum Virtual Machine interpreter within Redis using Lua-based Functions. By enabling Redis to directly interpret EVM opcodes, this innovation aims to drastically reduce SLOAD latency for eth_call operations. We'll explore the architecture, implementation challenges, and potential performance gains of this novel approach. Come discover how Redis EVM could reshape Ethereum execution environments, enhancing scalability and efficiency for dApps.",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
+ "expertise": "Expert",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "User Experience",
- "Intents",
- "defi",
- "Intents",
- "User Experience"
- ],
"keywords": [
- "DeFi"
+ "RPC",
+ "Execution"
+ ],
+ "tags": [
+ "Scalability",
+ "EVM-equivalent",
+ "Tooling",
+ "execution",
+ "EVM-equivalent",
+ "Scalability",
+ "Tooling"
],
- "duration": 2896,
"language": "en",
- "sources_swarmHash": "b62c90d88cd31739d845fd3c69549705e18eb151c919421eddbcaa08ad72ab94",
- "sources_youtubeId": "hId-FQUOpJ0",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731406200000,
- "slot_end": 1731409800000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1pQP77cQCgded-4Om05CtsNholtmf6N8hdDeVEVTDvKU",
- "resources_slides": null,
"speakers": [
- "agustin-grosso",
- "juli-corti",
- "ran-hammer",
- "dominik-hell",
- "shawn-odonaghue"
- ]
+ "everton-fraga"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731565200000,
+ "slot_end": 1731565800000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1fF69WpIZk0d5kqOiGISG9maJgrmsuKxAcyzfYSedRsw"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -622287,39 +620966,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -622329,6 +620975,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -622503,7 +621150,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -622661,23 +621307,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -622733,6 +621362,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -622860,6 +621490,38 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -623042,20 +621704,34 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
2,
0,
0,
@@ -623065,34 +621741,59 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
0
]
},
{
"session": {
- "id": "redefining-boundaries-in-the-infinite-garden",
- "sourceId": "FUZDNX",
- "title": "Redefining boundaries in the Infinite Garden",
- "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.",
+ "id": "reimagining-layer-0-new-worlds-and-ancient-philosophies",
+ "sourceId": "JPHQYQ",
+ "title": "Reimagining Layer 0: New Worlds and Ancient Philosophies",
+ "description": "Where the early internet was an expression of freedom, liberty, and democratising virtual spaces, etc. Today, our digital spaces are breaking and have not met that promise. The Web3 space also faces scams, degen behaviour, and capture by centralised actors. How do we guide Ethereum to stay aligned with human values as we build a new world? Revisiting ancient Asian philosophies can help us reimagine a new world from Layer0.",
"track": "Real World Ethereum",
"type": "Talk",
- "expertise": "",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Academic",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
- "language": "en",
- "speakers": [
- "aya-miyaguchi"
+ "tags": [
+ "Coordination",
+ "Political systems",
+ "Solarpunk",
+ "Regenative Ethereum",
+ "value",
+ "asian",
+ "Coordination",
+ "Political systems",
+ "Regenative Ethereum",
+ "Solarpunk"
+ ],
+ "keywords": [
+ "asian",
+ "values"
],
+ "duration": 1568,
+ "language": "en",
+ "sources_swarmHash": "3d225064900625c44f6ace62cf5e21ef0505517583e3365f6e57b9cebb8ddb67",
+ "sources_youtubeId": "rhDemdcnVVE",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731382800000,
- "slot_end": 1731384000000,
- "slot_roomId": "main-stage",
- "sources_youtubeId": "SE15rsPVHz0",
- "sources_swarmHash": "ad356189d2834782997d461c0a3e4b34ad700af2998a1d88369a28e185b406d0",
- "resources_presentation": "https://docs.google.com/presentation/d/1K5z-RKHIToQZFNAHUKMDOmuOsAKkNs4VPNUiIqAAe9M"
+ "slot_start": 1731390600000,
+ "slot_end": 1731392400000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1hKiZ-7BNfUDp8MUrH21ufSaRDdB7UK0-A4X85CDWHvg",
+ "resources_slides": null,
+ "speakers": [
+ "dev-lewis"
+ ]
},
"vector": [
0,
@@ -623276,15 +621977,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -623657,6 +622349,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -623958,6 +622651,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -623976,6 +622670,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -624005,6 +622700,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -624222,6 +622918,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -624232,6 +622929,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -624301,6 +622999,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -624412,8 +623111,6 @@
2,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -624422,6 +623119,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -624430,51 +623128,25 @@
},
{
"session": {
- "id": "redefining-daos-state-of-daos-in-asia",
- "sourceId": "PUMYRH",
- "title": "Redefining DAOs: State of DAOs in Asia",
- "description": "We are a team from Metagov and DAOstar, advancing the global DAO movement through standards like ERC-4824 and exploring diverse DAO narratives worldwide. We've commissioned multiple reports on the “State of DAOs” in Asia, covering Japan, South Korea, Taiwan, Singapore, Greater China, and SEA. Our panel will discuss these findings, focusing on DAO narratives, regulations, opportunities, and differences between Eastern and Western DAOs, aiming to bridge the gap in the global DAO discourse.",
- "track": "Coordination",
- "type": "Panel",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "remix-jazz-and-blues-jam",
+ "sourceId": "P8DPWB",
+ "title": "Remix Jazz and Blues Jam",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Coordination",
- "DAO",
- "Governance",
- "asia",
- "Coordination",
- "DAO",
- "Governance"
- ],
- "keywords": [
- "Standards",
- "Asia"
- ],
- "duration": 3320,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "Mwui5uJ7hSI",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731472200000,
- "slot_end": 1731475800000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1ieI7X9rFpOPzhR32w8gT6d_tE2y-xDKaSS2cr_K6lgE",
- "resources_slides": null,
- "speakers": [
- "joseph-low",
- "dev-lewis",
- "hazel-devjani",
- "gen",
- "yvonne"
- ]
+ "slot_start": 1731391200000,
+ "slot_end": 1731398400000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1gubgQAcUzwO-7G0PuYDVVhtDoG62piEJsVzXp4Pfrgw"
},
"vector": [
0,
@@ -624486,9 +623158,9 @@
0,
0,
0,
+ 6,
0,
0,
- 6,
0,
0,
0,
@@ -625034,11 +623706,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
- 6,
0,
0,
0,
@@ -625325,12 +623992,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -625384,7 +624049,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -625685,7 +624349,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -625792,12 +624455,13 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
+ 0,
0,
2,
0,
@@ -625807,55 +624471,47 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0
]
},
{
"session": {
- "id": "redis-evm-supercharging-ethereum-calls-with-in-memory-execution",
- "sourceId": "FKVE9X",
- "title": "Redis EVM: Supercharging Ethereum calls with in-memory execution",
- "description": "Redis EVM is a research project that embeds an Ethereum Virtual Machine interpreter within Redis using Lua-based Functions. By enabling Redis to directly interpret EVM opcodes, this innovation aims to drastically reduce SLOAD latency for eth_call operations. We'll explore the architecture, implementation challenges, and potential performance gains of this novel approach. Come discover how Redis EVM could reshape Ethereum execution environments, enhancing scalability and efficiency for dApps.",
- "track": "Core Protocol",
- "type": "Lightning Talk",
- "expertise": "Expert",
+ "id": "remix-team-jazz-jam",
+ "sourceId": "DFPGS9",
+ "title": "Remix Team Jazz Jam",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "RPC",
- "Execution"
- ],
- "tags": [
- "Scalability",
- "EVM-equivalent",
- "Tooling",
- "execution",
- "EVM-equivalent",
- "Scalability",
- "Tooling"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "everton-fraga"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731565200000,
- "slot_end": 1731565800000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1fF69WpIZk0d5kqOiGISG9maJgrmsuKxAcyzfYSedRsw"
+ "slot_start": 1731556800000,
+ "slot_end": 1731564000000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/15rbpsHykfj3g9nCDSuig1Spz-H0RvoW5Qg7cgHOO95M"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -626408,7 +625064,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -626619,7 +625274,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -626738,7 +625392,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -626793,7 +625446,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -626922,7 +625574,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -627163,6 +625814,8 @@
0,
0,
2,
+ 0,
+ 0,
2,
0,
0,
@@ -627181,59 +625834,44 @@
},
{
"session": {
- "id": "reimagining-layer-0-new-worlds-and-ancient-philosophies",
- "sourceId": "JPHQYQ",
- "title": "Reimagining Layer 0: New Worlds and Ancient Philosophies",
- "description": "Where the early internet was an expression of freedom, liberty, and democratising virtual spaces, etc. Today, our digital spaces are breaking and have not met that promise. The Web3 space also faces scams, degen behaviour, and capture by centralised actors. How do we guide Ethereum to stay aligned with human values as we build a new world? Revisiting ancient Asian philosophies can help us reimagine a new world from Layer0.",
- "track": "Real World Ethereum",
- "type": "Talk",
+ "id": "resilience-to-global-catastrophes",
+ "sourceId": "PZFHQF",
+ "title": "Resilience to Global Catastrophes",
+ "description": "The risk of nuclear war or an extreme pandemic is frighteningly high. Little work has been done on resilience to these catastrophes. I’ll discuss resilient food sources that can be scaled up quickly, methods of maintaining the functioning of critical sectors in an extreme pandemic, and backup methods of meeting basic needs. I’ll discuss cost effectiveness of low-cost preparations, including piloting technologies, such as resilient satellite communications, and a resilience DAO.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Academic",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Coordination",
- "Political systems",
- "Solarpunk",
- "Regenative Ethereum",
- "value",
- "asian",
- "Coordination",
- "Political systems",
- "Regenative Ethereum",
- "Solarpunk"
- ],
"keywords": [
- "asian",
- "values"
+ "Resilience",
+ "global catastrophic risk"
+ ],
+ "tags": [
+ "Climate",
+ "DAO",
+ "Effective Altruism"
],
- "duration": 1568,
"language": "en",
- "sources_swarmHash": "3d225064900625c44f6ace62cf5e21ef0505517583e3365f6e57b9cebb8ddb67",
- "sources_youtubeId": "rhDemdcnVVE",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731390600000,
- "slot_end": 1731392400000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1hKiZ-7BNfUDp8MUrH21ufSaRDdB7UK0-A4X85CDWHvg",
- "resources_slides": null,
"speakers": [
- "dev-lewis"
- ]
+ "david-denkenberger",
+ "yesh"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731582600000,
+ "slot_end": 1731583200000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1PtsLokONL6PEJ91cRee5o3KxGN3fLCjZ34KzGRksS0U"
},
"vector": [
0,
+ 6,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -627786,6 +626424,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -628076,6 +626715,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -628085,8 +626725,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -628104,7 +626742,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -628112,6 +626749,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -628134,7 +626772,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -628222,6 +626859,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -628353,7 +626991,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -628364,7 +627001,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -628436,7 +627072,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -628544,6 +627179,7 @@
0,
2,
0,
+ 2,
0,
0,
0,
@@ -628553,7 +627189,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -628562,32 +627197,39 @@
},
{
"session": {
- "id": "remix-jazz-and-blues-jam",
- "sourceId": "P8DPWB",
- "title": "Remix Jazz and Blues Jam",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
+ "id": "reth-10-how-did-we-get-here-and-what-is-next",
+ "sourceId": "UTDCDM",
+ "title": "Reth 1.0: How did we get here and what is next?",
+ "description": "Reth is an Ethereum Execution Layer in development since 2022, focused on contributor-friendliness, modularity and performance. \r\n\r\nIn 2024, after rigorous testing and security review, Reth had its first 1.0 prod-ready release. \r\n\r\nIn this talk, we review the process of shipping a state of the art & novel Ethereum node, and lay out Reth's plans for the next years.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "rust"
+ ],
+ "tags": [
+ "Core Protocol",
+ "Developer Infrastructure",
+ "Tooling",
+ "rust",
+ "Core Protocol",
+ "Developer Infrastructure",
+ "Tooling"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "georgios-konstantopoulos"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731391200000,
- "slot_end": 1731398400000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1gubgQAcUzwO-7G0PuYDVVhtDoG62piEJsVzXp4Pfrgw"
+ "slot_start": 1731486600000,
+ "slot_end": 1731488400000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1UdyIubnyXa-jfQkQkNDBDIP68YwdvTL9o61nG4a3fFU"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -629148,6 +627790,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -629355,7 +627998,9 @@
0,
0,
0,
+ 2,
0,
+ 2,
0,
0,
0,
@@ -629388,6 +628033,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -629788,10 +628434,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -629900,6 +628543,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -629918,32 +628562,50 @@
},
{
"session": {
- "id": "remix-team-jazz-jam",
- "sourceId": "DFPGS9",
- "title": "Remix Team Jazz Jam",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
+ "id": "rethinking-ethereums-account-model",
+ "sourceId": "GEEQXS",
+ "title": "Rethinking Ethereum’s account model",
+ "description": "Account centric models are inherently faster.\r\n\r\nEthereum operates on a global account based model. This means a global lock occurs any time someone needs to touch a piece of global state, such as an ERC20.\r\n\r\nAn account centric model, instead, creates a new deterministic address or state for each account. This means calls into transfers on ERC20s and dexes can be made in parallel, accelerating speed drastically. It also is more secure.\r\n\r\nIt’s a forgotten mechanism to scale ETH.",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
+ "expertise": "Expert",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "tags": [
+ "Core Protocol",
+ "Layer 1",
+ "Ethereum Roadmap",
+ "model",
+ "account",
+ "Core Protocol",
+ "Ethereum Roadmap",
+ "Layer 1"
+ ],
+ "keywords": [
+ "Account",
+ "Models"
+ ],
+ "duration": 537,
"language": "en",
- "speakers": [],
+ "sources_swarmHash": "de96bb25225be90b669409315ef858bc5a173e1424895908951a4f1344789bca",
+ "sources_youtubeId": "7B-ji-XrMio",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731556800000,
- "slot_end": 1731564000000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/15rbpsHykfj3g9nCDSuig1Spz-H0RvoW5Qg7cgHOO95M"
+ "slot_start": 1731465900000,
+ "slot_end": 1731466500000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1S8CtqAgd4RfP7bFHLKoa51ch_PX1Vkr5bs1-02-C3XE",
+ "resources_slides": null,
+ "speakers": [
+ "will-villanueva"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -630505,6 +629167,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -630707,9 +629370,11 @@
0,
0,
0,
+ 6,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -630882,6 +629547,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -631145,8 +629811,8 @@
0,
0,
0,
- 0,
- 0,
+ 2,
+ 2,
0,
0,
0,
@@ -631254,8 +629920,6 @@
0,
0,
2,
- 0,
- 0,
2,
0,
0,
@@ -631274,39 +629938,39 @@
},
{
"session": {
- "id": "resilience-to-global-catastrophes",
- "sourceId": "PZFHQF",
- "title": "Resilience to Global Catastrophes",
- "description": "The risk of nuclear war or an extreme pandemic is frighteningly high. Little work has been done on resilience to these catastrophes. I’ll discuss resilient food sources that can be scaled up quickly, methods of maintaining the functioning of critical sectors in an extreme pandemic, and backup methods of meeting basic needs. I’ll discuss cost effectiveness of low-cost preparations, including piloting technologies, such as resilient satellite communications, and a resilience DAO.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
+ "id": "rethinking-usability-in-a-world-of-data-ownership",
+ "sourceId": "RKNJED",
+ "title": "Rethinking usability in a world of data ownership",
+ "description": "What makes something usable in a world where the internet is built on open source cryptography? This talk explores how we might consider choice a key factor in the usability of applications where we are owners of our data which we can port, wield, and disclose at our discretion with other data owners. I will illustrate how we are testing our hypothesis that cryptography can surface meaningful connections through demo applications that embrace choice as a key usability factor.",
+ "track": "Usability",
+ "type": "Talk",
"expertise": "Beginner",
- "audience": "Engineering",
+ "audience": "",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Resilience",
- "global catastrophic risk"
+ "applications",
+ "social graphs",
+ "data ownership"
],
"tags": [
- "Climate",
- "DAO",
- "Effective Altruism"
+ "data",
+ "ownership",
+ "Best Practices",
+ "Design Thinking",
+ "MPC"
],
"language": "en",
"speakers": [
- "david-denkenberger",
- "yesh"
+ "rachel"
],
"eventId": "devcon-7",
- "slot_start": 1731582600000,
- "slot_end": 1731583200000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1PtsLokONL6PEJ91cRee5o3KxGN3fLCjZ34KzGRksS0U"
+ "slot_start": 1731468600000,
+ "slot_end": 1731470400000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1J2Pvcrn11ngEmYIecAN4U40wGXlrktRwNsT9I3TM-YM"
},
"vector": [
- 0,
- 6,
0,
0,
0,
@@ -631315,6 +629979,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -631869,7 +630534,6 @@
0,
0,
6,
- 6,
0,
0,
0,
@@ -632087,6 +630751,9 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
0,
0,
0,
@@ -632142,6 +630809,12 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -632158,7 +630831,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -632303,17 +630975,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -632369,6 +631030,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -632516,6 +631178,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -632622,7 +631285,6 @@
0,
2,
0,
- 2,
0,
0,
0,
@@ -632633,6 +631295,7 @@
0,
0,
0,
+ 2,
0,
0,
0
@@ -632640,46 +631303,54 @@
},
{
"session": {
- "id": "reth-10-how-did-we-get-here-and-what-is-next",
- "sourceId": "UTDCDM",
- "title": "Reth 1.0: How did we get here and what is next?",
- "description": "Reth is an Ethereum Execution Layer in development since 2022, focused on contributor-friendliness, modularity and performance. \r\n\r\nIn 2024, after rigorous testing and security review, Reth had its first 1.0 prod-ready release. \r\n\r\nIn this talk, we review the process of shipping a state of the art & novel Ethereum node, and lay out Reth's plans for the next years.",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "rethinking-user-risks-at-l2beat",
+ "sourceId": "8YKV8H",
+ "title": "Rethinking user risks at L2BEAT",
+ "description": "We want to announce a new L2BEAT feature of viewing protocol risks that individuals are actually exposed to. When we researched risks in the past users didn't find the information relevant, because they weren't aware they were using a specific protocol. Bridges are one example where users forgot about escrow risk as soon as the funds were bridged. In this talk we'll show how rollup risks translate into risks associated with individual assets held by users.",
+ "track": "Security",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "rust"
- ],
"tags": [
- "Core Protocol",
- "Developer Infrastructure",
- "Tooling",
- "rust",
- "Core Protocol",
- "Developer Infrastructure",
- "Tooling"
+ "Layer 2s",
+ "Token bridging",
+ "Security",
+ "trusted",
+ "Layer 2s",
+ "Security",
+ "Token bridging"
],
- "language": "en",
- "speakers": [
- "georgios-konstantopoulos"
+ "keywords": [
+ "risk",
+ "trust"
],
+ "duration": 523,
+ "language": "en",
+ "sources_swarmHash": "5426184a342e67741c5784af3fa3bad843721262e251fc34edd8c6527df7d9e9",
+ "sources_youtubeId": "CM6e_wwieeo",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731486600000,
- "slot_end": 1731488400000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1UdyIubnyXa-jfQkQkNDBDIP68YwdvTL9o61nG4a3fFU"
+ "slot_start": 1731406800000,
+ "slot_end": 1731407400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1eDeIVW8yw0TTm6i7x1PFeXMtab7BfMey3gIO056ytDw",
+ "resources_slides": null,
+ "speakers": [
+ "piotr-szlachciak"
+ ]
},
"vector": [
+ 6,
0,
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -633424,6 +632095,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -633444,9 +632116,6 @@
0,
0,
0,
- 2,
- 0,
- 2,
0,
0,
0,
@@ -633479,7 +632148,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -633493,6 +632161,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -633598,6 +632267,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -633628,6 +632298,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -633883,7 +632554,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -633990,12 +632660,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -634008,57 +632678,41 @@
},
{
"session": {
- "id": "rethinking-ethereums-account-model",
- "sourceId": "GEEQXS",
- "title": "Rethinking Ethereum’s account model",
- "description": "Account centric models are inherently faster.\r\n\r\nEthereum operates on a global account based model. This means a global lock occurs any time someone needs to touch a piece of global state, such as an ERC20.\r\n\r\nAn account centric model, instead, creates a new deterministic address or state for each account. This means calls into transfers on ERC20s and dexes can be made in parallel, accelerating speed drastically. It also is more secure.\r\n\r\nIt’s a forgotten mechanism to scale ETH.",
- "track": "Core Protocol",
- "type": "Lightning Talk",
- "expertise": "Expert",
+ "id": "reverse-engineering-evm-bytecode-with-ghidra",
+ "sourceId": "GSJ8EC",
+ "title": "Reverse Engineering EVM Bytecode with Ghidra",
+ "description": "Ghidra is a popular tool in reverse engineering. We developed Mothra, a Ghidra extension that enables it to work with EVM bytecode. Disassembly, CFG, and decompilation of EVM bytecode are now possible within Ghidra. In this workshop, we will discuss how Mothra is implemented and how to reverse engineer EVM smart contracts using Ghidra.",
+ "track": "Security",
+ "type": "Workshop",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
- "doNotRecord": false,
- "tags": [
- "Core Protocol",
- "Layer 1",
- "Ethereum Roadmap",
- "model",
- "account",
- "Core Protocol",
- "Ethereum Roadmap",
- "Layer 1"
- ],
+ "doNotRecord": true,
"keywords": [
- "Account",
- "Models"
+ "Security"
+ ],
+ "tags": [
+ "Security",
+ "Reversing",
+ "Reversing"
],
- "duration": 537,
"language": "en",
- "sources_swarmHash": "de96bb25225be90b669409315ef858bc5a173e1424895908951a4f1344789bca",
- "sources_youtubeId": "7B-ji-XrMio",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731465900000,
- "slot_end": 1731466500000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1S8CtqAgd4RfP7bFHLKoa51ch_PX1Vkr5bs1-02-C3XE",
- "resources_slides": null,
"speakers": [
- "will-villanueva"
- ]
+ "yuejie",
+ "louis-tsai"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731654000000,
+ "slot_end": 1731659400000,
+ "slot_roomId": "classroom-d",
+ "resources_presentation": "https://docs.google.com/presentation/d/1cpw84aROzg-pzvJ3BWMKjrp6Dqvqw_OF_Xga5Rc8UU0"
},
"vector": [
+ 6,
0,
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -634619,6 +633273,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -634802,6 +633457,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -634819,11 +633475,9 @@
0,
0,
0,
- 6,
0,
0,
0,
- 2,
0,
0,
0,
@@ -634996,7 +633650,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -635264,7 +633917,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -635366,9 +634018,10 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
- 2,
2,
0,
0,
@@ -635387,49 +634040,49 @@
},
{
"session": {
- "id": "rethinking-usability-in-a-world-of-data-ownership",
- "sourceId": "RKNJED",
- "title": "Rethinking usability in a world of data ownership",
- "description": "What makes something usable in a world where the internet is built on open source cryptography? This talk explores how we might consider choice a key factor in the usability of applications where we are owners of our data which we can port, wield, and disclose at our discretion with other data owners. I will illustrate how we are testing our hypothesis that cryptography can surface meaningful connections through demo applications that embrace choice as a key usability factor.",
- "track": "Usability",
+ "id": "revm-endgame",
+ "sourceId": "VEEYFZ",
+ "title": "Revm Endgame",
+ "description": "Revm is a critical component of the Ethereum ecosystem, used by builders, toolings and clients. It is an audited and proven library that is both fast and easy to use.\r\n\r\nAs more projects adopt Revm, I feel the increasing burden of making breaking changes and the need to consolidate its functionality. That’s why I am thinking about Revm Endgame, a solution to support experimentation, Layer 2 features, and EIPs without the need for repository forks.",
+ "track": "Core Protocol",
"type": "Talk",
- "expertise": "Beginner",
- "audience": "",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "applications",
- "social graphs",
- "data ownership"
+ "EVM"
],
"tags": [
- "data",
- "ownership",
- "Best Practices",
- "Design Thinking",
- "MPC"
+ "Core Protocol",
+ "Architecture",
+ "Public good",
+ "execution",
+ "client",
+ "Architecture",
+ "Core Protocol",
+ "Public good"
],
"language": "en",
"speakers": [
- "rachel"
+ "dragan-rakita"
],
"eventId": "devcon-7",
- "slot_start": 1731468600000,
- "slot_end": 1731470400000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1J2Pvcrn11ngEmYIecAN4U40wGXlrktRwNsT9I3TM-YM"
+ "slot_start": 1731558600000,
+ "slot_end": 1731560400000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Eqr32OyHNOUkt06oQXAiVNTwZse9uMoY_tw7Ag2SkQs"
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -636189,6 +634842,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -636203,7 +634864,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -636225,6 +634885,17 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -636316,6 +634987,37 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
2,
0,
0,
@@ -636483,7 +635185,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -636633,60 +635334,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -636735,6 +635382,12 @@
0,
0,
0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
2,
0,
0,
@@ -636747,59 +635400,40 @@
0,
0,
0,
- 2,
- 0,
0,
0
]
},
{
"session": {
- "id": "rethinking-user-risks-at-l2beat",
- "sourceId": "8YKV8H",
- "title": "Rethinking user risks at L2BEAT",
- "description": "We want to announce a new L2BEAT feature of viewing protocol risks that individuals are actually exposed to. When we researched risks in the past users didn't find the information relevant, because they weren't aware they were using a specific protocol. Bridges are one example where users forgot about escrow risk as soon as the funds were bridged. In this talk we'll show how rollup risks translate into risks associated with individual assets held by users.",
- "track": "Security",
- "type": "Lightning Talk",
+ "id": "rip-7755-empowering-cross-chain-interactions",
+ "sourceId": "787TJ7",
+ "title": "RIP-7755: Empowering Cross-Chain Interactions",
+ "description": "Cross-chain interactions are becoming essential as Ethereum Layer 2 solutions multiply. RIP-7755 changes the game by trustlessly bridging the gap between L2 chains, allowing new use cases that rely solely on Ethereum and its rollups. In this workshop, we’ll explore RIP-7755 by building a cross-chain NFT minting app, focusing on nested storage proof implementation details to eliminate trust assumptions.",
+ "track": "Layer 2",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Layer 2s",
- "Token bridging",
- "Security",
- "trusted",
- "Layer 2s",
- "Security",
- "Token bridging"
- ],
"keywords": [
- "risk",
- "trust"
+ "Interop"
+ ],
+ "tags": [
+ "Cross-L2",
+ "Rollups"
],
- "duration": 523,
"language": "en",
- "sources_swarmHash": "5426184a342e67741c5784af3fa3bad843721262e251fc34edd8c6527df7d9e9",
- "sources_youtubeId": "CM6e_wwieeo",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731406800000,
- "slot_end": 1731407400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1eDeIVW8yw0TTm6i7x1PFeXMtab7BfMey3gIO056ytDw",
- "resources_slides": null,
"speakers": [
- "piotr-szlachciak"
- ]
+ "jack-chuma"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731645000000,
+ "slot_end": 1731652200000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/1R-pN3is6_qjmy7k7gl3hHECFG1O_ZDuH33K5B6JQmGc"
},
"vector": [
- 6,
- 0,
0,
0,
0,
@@ -636807,6 +635441,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -637550,7 +636185,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -637591,6 +636225,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -637616,7 +636251,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -637722,7 +636356,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -637750,10 +636383,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -638115,12 +636748,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -638133,44 +636766,59 @@
},
{
"session": {
- "id": "reverse-engineering-evm-bytecode-with-ghidra",
- "sourceId": "GSJ8EC",
- "title": "Reverse Engineering EVM Bytecode with Ghidra",
- "description": "Ghidra is a popular tool in reverse engineering. We developed Mothra, a Ghidra extension that enables it to work with EVM bytecode. Disassembly, CFG, and decompilation of EVM bytecode are now possible within Ghidra. In this workshop, we will discuss how Mothra is implemented and how to reverse engineer EVM smart contracts using Ghidra.",
- "track": "Security",
+ "id": "rlnv2-enhanced-spam-protection-for-all-peer-to-peer-networks",
+ "sourceId": "ZFJXFP",
+ "title": "RLNv2: enhanced spam protection for all peer-to-peer networks",
+ "description": "RLN is a protocol designed to prevent DoS attacks in a privacy-preserving manner. It uses zero-knowledge proof to limit the number of actions a user can take. In a p2p network, it can be used to limit messages sent over a period of time by one sender. RLN’s latest upgrade limits to N (instead of 1) messages per epoch. Also, the Merkle tree is now built on-chain, greatly improving the UX.\r\n\r\nCome learn how to use an implementation of RLNv2 to DoS protect a peer-to-peer network.",
+ "track": "Cypherpunk & Privacy",
"type": "Workshop",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developer",
"featured": false,
- "doNotRecord": true,
- "keywords": [
- "Security"
- ],
+ "doNotRecord": false,
"tags": [
- "Security",
- "Reversing",
- "Reversing"
+ "Privacy",
+ "Censorship Resistance",
+ "Decentralization",
+ "Zero-Knowledge",
+ "network",
+ "peer-to-peer",
+ "Censorship Resistance",
+ "Decentralization",
+ "Privacy",
+ "Zero-Knowledge"
],
- "language": "en",
- "speakers": [
- "yuejie",
- "louis-tsai"
+ "keywords": [
+ "Anonymity",
+ "peer-to-peer networks"
],
+ "duration": 3144,
+ "language": "en",
+ "sources_swarmHash": "6ea0528ba8f1725dea3e57b64456bbc3b2119584f9f8c6c02f8558bd98ae88e5",
+ "sources_youtubeId": "EH6zUu6AzlQ",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731654000000,
- "slot_end": 1731659400000,
- "slot_roomId": "classroom-d",
- "resources_presentation": "https://docs.google.com/presentation/d/1cpw84aROzg-pzvJ3BWMKjrp6Dqvqw_OF_Xga5Rc8UU0"
+ "slot_start": 1731483000000,
+ "slot_end": 1731488400000,
+ "slot_roomId": "classroom-c",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ab7Dm_NLmbdVl-rQdbpavpCT-nXILHwBPKMRvciyvFQ",
+ "resources_slides": null,
+ "speakers": [
+ "franck-royer",
+ "alvaro"
+ ]
},
"vector": [
- 6,
- 0,
- 0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -638272,6 +636920,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -638733,10 +637382,6 @@
0,
0,
6,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -638915,9 +637560,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -638932,6 +637574,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -639007,6 +637650,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -639020,6 +637664,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -639033,6 +637678,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -639064,6 +637710,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -639375,9 +638022,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -639480,9 +638127,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -639498,47 +638145,50 @@
},
{
"session": {
- "id": "revm-endgame",
- "sourceId": "VEEYFZ",
- "title": "Revm Endgame",
- "description": "Revm is a critical component of the Ethereum ecosystem, used by builders, toolings and clients. It is an audited and proven library that is both fast and easy to use.\r\n\r\nAs more projects adopt Revm, I feel the increasing burden of making breaking changes and the need to consolidate its functionality. That’s why I am thinking about Revm Endgame, a solution to support experimentation, Layer 2 features, and EIPs without the need for repository forks.",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "road-to-effective-public-goods-funding-through-quantitative-cross-comparative-analysis-of-grants-programs",
+ "sourceId": "NHERZE",
+ "title": "Road to Effective Public Goods Funding through Quantitative Cross-Comparative Analysis of Grants Programs",
+ "description": "I aim to achieve effective public goods funding by comparing grants models. Grants programs are key in the crypto ecosystem, but comparative studies are rare. Our study compares Uniswap, dYdX, Optimism, Gitcoin, and more, categorizing them into \"top-down,\" \"bottom-up,\" and \"QF (algorithmic)\" types. Findings suggest bottom-up and QF types distribute funds more evenly with smaller variability and grant amounts, while top-down types show greater variability with larger grants for fewer grantees.",
+ "track": "Coordination",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "EVM"
+ "Grants Program",
+ "Public Goods Funding"
],
"tags": [
- "Core Protocol",
- "Architecture",
+ "Coordination",
+ "DAO",
+ "Governance",
+ "Regenative Ethereum",
"Public good",
- "execution",
- "client",
- "Architecture",
- "Core Protocol",
- "Public good"
+ "funding",
+ "public",
+ "goods",
+ "Coordination",
+ "DAO",
+ "Governance",
+ "Public good",
+ "Regenative Ethereum"
],
"language": "en",
"speakers": [
- "dragan-rakita"
+ "shinya-mori"
],
"eventId": "devcon-7",
- "slot_start": 1731558600000,
- "slot_end": 1731560400000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1Eqr32OyHNOUkt06oQXAiVNTwZse9uMoY_tw7Ag2SkQs"
+ "slot_start": 1731640800000,
+ "slot_end": 1731641400000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1el9pBQpo_PXoaMz4cdOtMT4cXnCNpLdicORmmniTBK4"
},
"vector": [
0,
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -639546,6 +638196,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -640303,8 +638954,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -640346,7 +638995,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -640382,10 +639030,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -640439,6 +639089,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -640479,11 +639130,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -640601,6 +639247,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -640671,6 +639318,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -640747,6 +639395,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -640849,8 +639499,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -640867,32 +639517,35 @@
},
{
"session": {
- "id": "rip-7755-empowering-cross-chain-interactions",
- "sourceId": "787TJ7",
- "title": "RIP-7755: Empowering Cross-Chain Interactions",
- "description": "Cross-chain interactions are becoming essential as Ethereum Layer 2 solutions multiply. RIP-7755 changes the game by trustlessly bridging the gap between L2 chains, allowing new use cases that rely solely on Ethereum and its rollups. In this workshop, we’ll explore RIP-7755 by building a cross-chain NFT minting app, focusing on nested storage proof implementation details to eliminate trust assumptions.",
- "track": "Layer 2",
- "type": "Workshop",
+ "id": "rohingya-decentralized-identity-and-community-building",
+ "sourceId": "G8W8MU",
+ "title": "Rohingya Decentralized Identity and Community Building",
+ "description": "The Rohingya Project is a transformative digital platform addressing the critical needs of the Rohingya community, focusing on empowerment and cultural preservation. Key services include R-ID, a decentralized identity verification system ensuring privacy and access to opportunities, and R-Academy, which offers courses on Rohingya culture and personal development. The Heritage Archive provides access to cultural resources, while the Community Exchange fosters collaboration & economic development.",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Interop"
+ "Rohingya",
+ "Decentralized Identity",
+ "inclusion"
],
"tags": [
- "Cross-L2",
- "Rollups"
+ "Decentralization",
+ "Digital Sovereignty",
+ "Ethereum for Good"
],
"language": "en",
"speakers": [
- "jack-chuma"
+ "muhammad-noor"
],
"eventId": "devcon-7",
- "slot_start": 1731645000000,
- "slot_end": 1731652200000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/1R-pN3is6_qjmy7k7gl3hHECFG1O_ZDuH33K5B6JQmGc"
+ "slot_start": 1731572400000,
+ "slot_end": 1731573000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1UYUaHo5Qavbvjs-V4IY1wgEZga3-zWvPCG7PXENX-k4"
},
"vector": [
0,
@@ -640901,7 +639554,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -641466,7 +640118,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -641689,9 +640340,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -641699,6 +640347,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -641750,6 +640399,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -641773,6 +640423,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -641847,7 +640498,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -642212,12 +640862,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -642230,51 +640880,39 @@
},
{
"session": {
- "id": "rlnv2-enhanced-spam-protection-for-all-peer-to-peer-networks",
- "sourceId": "ZFJXFP",
- "title": "RLNv2: enhanced spam protection for all peer-to-peer networks",
- "description": "RLN is a protocol designed to prevent DoS attacks in a privacy-preserving manner. It uses zero-knowledge proof to limit the number of actions a user can take. In a p2p network, it can be used to limit messages sent over a period of time by one sender. RLN’s latest upgrade limits to N (instead of 1) messages per epoch. Also, the Merkle tree is now built on-chain, greatly improving the UX.\r\n\r\nCome learn how to use an implementation of RLNv2 to DoS protect a peer-to-peer network.",
- "track": "Cypherpunk & Privacy",
- "type": "Workshop",
+ "id": "running-ethereum-node-in-africa",
+ "sourceId": "XT8ZWL",
+ "title": "Running Ethereum Node In Africa",
+ "description": "Running an Ethereum node in Africa presents both challenges and opportunities. It enables participation in the global blockchain ecosystem while contributing to network security and decentralization. Key points to highlight include overcoming infrastructure limitations, leveraging community support, the potential for economic empowerment through staking, and fostering local innovation and adoption. Emphasize the importance of education, collaboration, and strategic partnerships to",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Stakers/Validators",
"featured": false,
"doNotRecord": false,
+ "keywords": [
+ "Geographical",
+ "Diversity"
+ ],
"tags": [
- "Privacy",
- "Censorship Resistance",
+ "Home staking",
+ "Distributed validator technology",
"Decentralization",
- "Zero-Knowledge",
- "network",
- "peer-to-peer",
- "Censorship Resistance",
+ "diversity",
+ "geographical",
"Decentralization",
- "Privacy",
- "Zero-Knowledge"
- ],
- "keywords": [
- "Anonymity",
- "peer-to-peer networks"
+ "Distributed validator technology",
+ "Home staking"
],
- "duration": 3144,
"language": "en",
- "sources_swarmHash": "6ea0528ba8f1725dea3e57b64456bbc3b2119584f9f8c6c02f8558bd98ae88e5",
- "sources_youtubeId": "EH6zUu6AzlQ",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731483000000,
- "slot_end": 1731488400000,
- "slot_roomId": "classroom-c",
- "resources_presentation": "https://docs.google.com/presentation/d/1ab7Dm_NLmbdVl-rQdbpavpCT-nXILHwBPKMRvciyvFQ",
- "resources_slides": null,
"speakers": [
- "franck-royer",
- "alvaro"
- ]
+ "david-uzochukwu"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731575400000,
+ "slot_end": 1731576000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1buMXIg1gOhRzKk22wUllHQbcl9xVPk1mQ7_JHDKF_oQ"
},
"vector": [
0,
@@ -642282,9 +640920,8 @@
0,
0,
0,
- 6,
- 0,
0,
+ 6,
0,
0,
0,
@@ -642385,7 +641022,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -642679,6 +641315,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -642850,7 +641487,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -643041,7 +641677,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -643115,9 +641750,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -643145,7 +641780,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -643160,6 +641794,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -643177,7 +641812,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -643492,8 +642126,9 @@
0,
0,
0,
- 2,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -643596,11 +642231,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -643612,46 +642247,50 @@
},
{
"session": {
- "id": "road-to-effective-public-goods-funding-through-quantitative-cross-comparative-analysis-of-grants-programs",
- "sourceId": "NHERZE",
- "title": "Road to Effective Public Goods Funding through Quantitative Cross-Comparative Analysis of Grants Programs",
- "description": "I aim to achieve effective public goods funding by comparing grants models. Grants programs are key in the crypto ecosystem, but comparative studies are rare. Our study compares Uniswap, dYdX, Optimism, Gitcoin, and more, categorizing them into \"top-down,\" \"bottom-up,\" and \"QF (algorithmic)\" types. Findings suggest bottom-up and QF types distribute funds more evenly with smaller variability and grant amounts, while top-down types show greater variability with larger grants for fewer grantees.",
- "track": "Coordination",
- "type": "Lightning Talk",
+ "id": "running-wargames-to-prepare-protocol-teams-for-incident-response",
+ "sourceId": "N3DBC3",
+ "title": "Running Wargames to Prepare Protocol Teams for Incident Response",
+ "description": "SEAL (Security Alliance) Wargames: cybersecurity exercises designed to enhance Web3 protocol resilience. We'll share experiences from running these with major Ethereum protocols, covering:\r\n-Exercise structure: OSINT, tabletops, and live simulations on forked networks\r\n-Scenario designs and common vulnerabilities\r\n-Infrastructure and open-source tooling\r\n-Key learnings and best practices\r\n-Scaling strategies and the importance of regular security drills in the evolving Web3 landscape",
+ "track": "Security",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Grants Program",
- "Public Goods Funding"
- ],
"tags": [
"Coordination",
- "DAO",
- "Governance",
- "Regenative Ethereum",
- "Public good",
- "funding",
- "public",
- "goods",
+ "Security",
+ "incident",
+ "response",
"Coordination",
- "DAO",
- "Governance",
- "Public good",
- "Regenative Ethereum"
+ "Security"
],
- "language": "en",
- "speakers": [
- "shinya-mori"
+ "keywords": [
+ "Incident",
+ "Response"
],
+ "duration": 1350,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "mIOEkVh6aGM",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": "6732febd80d989c5b7b49fc9",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732febd80d989c5b7b49fc9.vtt",
+ "transcript_text": " And I also lead the War Games initiative for the Security Alliance. I'll give a brief introduction to just what the Security Alliance is and what the various initiatives are, because I think it's actually pretty relevant also after the first talk about ENS and data sharing. And so the top initiative here is actually called the SEAL-ISAC, which is not me, I'm SEAL-ISAC. This is the Information Security something something, which basically this is like a shared database between many different companies where they can share data on like DPRK threat actors or phishing data or bad domains. There's SEAL War Games, which is the initiative that I lead, where we prepare protocol teams for incident response through both tabletop simulations and then live simulations on forked environments. SEAL also operates SEAL 911, the emergency hotline, if your protocol is under attack or if you have discovered a vulnerability in a protocol and need to get in touch with a security expert as fast as possible. The Safe Harbor Agreement, which is legal protection if you're a white hat hacker and you're acting benevolently in an urgent situation to rescue funds from a protocol. Think Nomad Bridge hack a few years ago if you were trying to save money, but maybe you were worried because you thought that you'd be sued for hacking during because it'd be impossible to distinguish. The White Hat Safe Harbor Agreement exists to protect white hat hackers in those situations and a legal defense fund in case they sue you anyway. So today what we'll talk about primarily is war games. So what are these war games and why do we do them? I'll have some links to resources on how you can work with us. There's a lot of open source toolkits and we also run these as like a public good throughout the space. We'll be talking through some best practices that I've learned from working with some of the major protocols in the ecosystem and then just briefly show you what this new toolkit is that we released so you can run these yourself if you would like. So what are wargames? These are cybersecurity exercises for Web3. I've heard traditional cybersecurity folks call these something like a purple team exercise, where we're not exactly red team, blue team, but we're basically just trying to stress test these teams and understand how they behave under pressure. And so we want to help teams practice for these high-pressure situations before they actually happen. We want to be able to test both the technical side of their team and their social resilience. And we're not just trying to help cause them to panic, but we want them to practice emergency response. A lot of the reason why we started doing this was a few years ago. So the security lines was started by Sam Sun, and he was pulled into so many war rooms where it seemed like, I guess, from what I've heard, teams just completely melting down and not really being exactly prepared for what would happen. So what could we actually do to help put them in that situation before that inevitably happens? So war games take place through three phases. I do a lot of intelligence gathering, which really just means reading every document that the protocol's ever published, understand their contracts, understand how it works. We do a tabletop exercise where we talk through various scenarios with them and understand how they would have detected them, what they would do, who's in charge, and how would they have fixed something. And then what I think is the most fun is we do a live simulation. So we set up a forked environment, we run all of their contracts, we write all of their UIs, we run all of their monitoring, and then they actually have to coordinate in real time to defend and respond as if it was a real incident. And we tend to find a lot of things that they can improve through that process, and it also just helps the team build trust in each other so that they know when an incident goes down for real, I can trust my team to be there. So a big reason why we do this is because more and more hacks are due to operational failures, not smart contract bugs. That's a really, I think, good sign that we're making fewer and fewer dumb mistakes on the smart contract side. However, as all of the stuff that we're building is becoming such a critical component of global financial infrastructure, the stakes are higher to actually operationally be strong as well. And so whether that's things like supply chain attacks or social engineering, it's much harder now than just not including dumb bugs in your smart contracts. So these are cross-functional exercises. We're not just working with the development team. They're of course a core part of it, but we're also tending to work with their auditors if they're a big protocol that has a guardian multi-sig that's in charge of pausing the protocol in case of emergency. We of course work with them. Communications team is actually essential so that we know what would they be communicating out to the public and when during an incident and legal so that they can say, okay, if we were to take this action perhaps to protect the users of our protocol, can we do that? Should we do that? And what should we be saying? The conversations between communications, legal, and devs should really be things that are figured out in advance so that during the incident,'re not thinking like do we tweet out that we're under attack right now or do we say something cryptic or what do we say like these are things that you can just have in a playbook so that you don't have to think about it in the moment. We've worked with a number of products of protocols so far but the purpose of this slide is also just to show you like why teams are working with us, it's because teams are growing. These are global teams, and it's really hard to prepare for this type of thing. There's many ways to engage with us. If you're a protocol that wants to work with a security alliance and have a drill performed with you, there's a form on the website, and there's also open source resources for you to be able to run these yourself. So this is a quote that I had a really hard time attributing. The internet said it was either like a Greek poet or the Navy Seals, but I think that it really like stands to to show like why we do this and it's that under pressure we don't rise to the occasion, we sink to our level of training. Yeah I think that that speaks to why we do this. So each one of these builds is quite different. A lot of protocols have various sorts of custom infrastructure and monitoring. So every time we do this, we end up having to build a lot of things. And we've tried to combine all of those tools and things that we've learned on how to run these simulations into this drill template that you can see here. It's on the Security Alliance GitHub repository. But what are the things that we do to make the environment feel realistic? So we of course have to run a network fork. We're usually either doing that with Anvil or with Tenderly. We have to run a block explorer, so we're either running Block Scout or using a virtual test net. We're running monitoring, so it's essential to mirror the same monitoring that you would have on main net.",
"eventId": "devcon-7",
- "slot_start": 1731640800000,
- "slot_end": 1731641400000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1el9pBQpo_PXoaMz4cdOtMT4cXnCNpLdicORmmniTBK4"
+ "slot_start": 1731390600000,
+ "slot_end": 1731392400000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Vl9aDLrFn0_bNTA3ddPbHqxDjrCLUyNEIUn4eBlSNzE",
+ "resources_slides": null,
+ "speakers": [
+ "isaac-patka",
+ "kelsie-nabben"
+ ]
},
"vector": [
+ 6,
0,
0,
0,
@@ -643663,7 +642302,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -644223,10 +642861,11 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -644400,6 +643039,50 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -644500,12 +643183,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -644559,7 +643240,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -644718,7 +643398,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -644789,7 +643468,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -644818,59 +643496,16 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 2,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 2,
0,
0,
0,
@@ -644970,10 +643605,10 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -644987,35 +643622,41 @@
},
{
"session": {
- "id": "rohingya-decentralized-identity-and-community-building",
- "sourceId": "G8W8MU",
- "title": "Rohingya Decentralized Identity and Community Building",
- "description": "The Rohingya Project is a transformative digital platform addressing the critical needs of the Rohingya community, focusing on empowerment and cultural preservation. Key services include R-ID, a decentralized identity verification system ensuring privacy and access to opportunities, and R-Academy, which offers courses on Rohingya culture and personal development. The Heritage Archive provides access to cultural resources, while the Community Exchange fosters collaboration & economic development.",
- "track": "Real World Ethereum",
+ "id": "samba-a-besu-portal-client",
+ "sourceId": "FTC8PQ",
+ "title": "Samba, a Besu Portal Client",
+ "description": "A presentation about my experience participating in the EPF. Talking primarily about the project I worked on for the cohort and various obstacles that I faced along the way. I additionally aim to go into detail about where I see Samba going in the future and my role in that development.",
+ "track": "[CLS] EPF Day",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Rohingya",
- "Decentralized Identity",
- "inclusion"
- ],
"tags": [
- "Decentralization",
- "Digital Sovereignty",
- "Ethereum for Good"
+ "Portal",
+ "network"
],
- "language": "en",
- "speakers": [
- "muhammad-noor"
+ "keywords": [
+ "EPF"
],
+ "duration": 705,
+ "language": "en",
+ "sources_swarmHash": "e02934d00bab1d926fea5b2862138be2ad9176107861f2ad27b01d9f661df389",
+ "sources_youtubeId": "g9P0Lu2qqnI",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67342b249dbb7a90e1bd5b22.vtt",
+ "transcript_text": " . All right. Yes. So I am Derek. Unfortunately, my partner Meltson wasn't able to make it. But yeah, our joint project is Bezu portal client, Samba. So. Yes, so I guess I'll give a brief introduction to Portal, because I think a lot of the reasons that I wanted to work on this project were just because I found Portal to be such an interesting topic. And so, there we go. So for the purposes of SOMB up to the scope of EPF, which is just for a few main roles through the history subnetwork. Portal network provides a solution to the proposed changes in EIP-44s that allows for the drastic limiting of storage requirements to run a node. As well, it also provides a way to handle the sharing of data in a way that not only can handle scaling, but actually benefits from scaling. And these benefits also directly link to Ethereum usability in lowering the barrier of entry to participation in the Ethereum ecosystem. And then as well, outside of the scope of EPF, as we continue, Portal also contains proposed solutions to managing state and beacon chain-related information, although this is somewhat more preliminary. Oh, there we go. And so now moving into the role of Samba in Portal, although this is somewhat more preliminary. There we go. Now moving into the role of Samba in Portal. There we go. So there's kind of two main roles Samba can play in this big kind of puzzle. One of the big roles is, of course, to fill the gap in the consensus hyperledger ecosystem in terms of a long-term EIP-4IP44 solution in regard to the existence of Samba. This also works to increase the portal client diversity in addition to ease of use in terms of the base of execution clients. But I think the other one and potentially more exciting in my eyes is its unique position compared to other portal clients in that it has a way to easily bring portal functionality to different Android, to the Android ecosystem with the benefit of the inherent modularity of Java, but also its native support. And so it's a very realistic goal to expect that Samba could simply be built on top of, as a library for other mobile or resource constrained applications. And so, moving into where Samba is at right now, my initial proposal at the beginning was extremely ambitious, and I admit that obviously not quite where we got to, but essentially this proposal is a model of where Samba will be at one point. And so all communications and related infrastructure, including disk B5, portal wire, and UTP, are eventually going to be implemented, mainly UTP at this point, it's the one that we're working on. And then to have a fully functioning history network, as well as full function of state beacon, state and beacon to the point of present portal development, as well as full interoperability with other portal clients. And so our updated goal range, of course, for the scope of EPF up to this point just pertains to what we figured would be reasonable in this time scope, but essentially that's to get, to have had primary communication infrastructure including a Discovery V5 and then the portal wire. Unfortunately, UTP was a big setback in the sense that there is no generalized UTP library, and so unfortunately we're not able to piggyback off anything like that and will have to be something that we sit down and do ourselves. And then to have infrastructure in place where history network function. And so then moving on, once we have that infrastructure and that we have is to have generalized internal testing, we wanted to have SSD sterilization, deserialization, exposed API infrastructure, metrics. And the only thing on the list that we weren't quite able to achieve in this goal range is portal hive testing. Unfortunately, just given the scope, we are very close to having had it. A lot of it was just putting little pieces together to test it, but we figured it'd be better to just add more functionality before we go and add just small pieces of testing, as opposed to now we can, as we go forward, add a lot more tests and then prove that we can then interop with other clients. And so this is a general diagram of kind of how Samba functions and the layout of Samba. And the big two pieces on the bottom here are the ones that really took the brunt of the time is getting all the base protocol communication systems in place. And so that includes like inbound, outbound communication. Whether that be coming from a client, there's a different way to handle requests coming in as opposed to sending out requests or then receiving inbound requests or responses and vice versa. But then of course there's other pieces of the puzzle such as the API which Meltzun had done in Expose an API. So we're very well set up to then start actually serving different pieces, such as the disk v5 and history, portal history APIs. And so, moving forward in the project, the future of Samba, obviously the development of Samba does not stop with EPF. The project is in a very good place infrastructure-wise and has achieved a lot of milestones in terms of functionality. Like at this point currently, we are able to send and receive all different types, all the available portal wire packets to all the other portal clients. And in terms of certain packet types, such as ping pong, obviously work well. And then we are able to now up to this point almost full functionality on just sending and receiving nodes in terms of building our peers. And so moving forward then the continued development will eventually bring us up to date with the other portal clients. And so that is, to me, also an exciting part of being a part of Portal is that for the development of Samba, we have EPF. But then also, moving after EPF, there's a portion of getting fully caught up to other portal clients. But then in terms of, I guess, my experience, it's also very exciting in that once we get to that point, it's an entirely different development paradigm where instead of catching up and following different specs, it's now actively participating in development. And so this development is much more something that I will have to learn as well, and that kind of brings me to, I would like to talk a bit about my EPF experience, because I think that was a really big part of this program for me, is just a lot of the learning that I've done. And so I think for me, there's definitely too many skills to list here. But if I were to sum it up, EPF was my introduction to Ethereum. Before EPF, I didn't know what Ethereum was. I didn't even know what blockchain technology was. So for me, that was a huge, just to get into the space and learn everything. And of course, that brought a huge confidence boost in terms of development. I previously, you know, I've never worked on such a large-scale project before. And so those organizational skills that are required to create that project was huge to me, and definitely gives me a lot more confidence moving forward in terms of developing projects and continuing to work on this project. As well, I think I acquired a lot of new learning skills. For me, I think I could best describe it as I learned how to learn. So I guess the biggest example for, in my case, is going through and learning the consensus discovery of V5 library. I had never had such a large scale library that I had to learn in the past. And so learning this library and then automatically going over to the Techu library and then learning the SSC internal infrastructure was a way to then quickly apply the skills that I just learned to then learn a new library, which was a really great experience. And as well, it gave me a project I really enjoy working on and of course will continue working on. And so yeah, the Samba repository can be found onelson's GitHub. I hope that one day we can have a hyperledger or consensus repository for that name. And then of course, I'd like to give a big thank you to Melson, unfortunately he wasn't able to be here, but he's been a great partner, great working with you Melson if you're watching. And then my friend and mentor, Colby. So unfortunately I can't say that to Colby. If you're interested more in Portal, his talk is going on, I believe, on stage two right now. And then, of course, EPF organizers, Josh and Mario. It's been a really great experience. I really thank you for this. But yeah, thank you. Thank you so much, Derek. I really appreciate it. I really appreciate your words and also your experience with EPF. It's amazing to see. I'm also going to make it. I met him in Argentina a week ago. He's also a great person. Couldn't come, but he will be still also contributing to Samba. Anyone has a question about Portal, about the best Java implementation, yeah. Yeah, just kind of a general question, like if you're still working on UTP, how are you doing the interop testing to verify correctness with the other portal clients? So for interop testing, there's a lot more than just actual content sharing testing, like for example, just the propagation of peers is one thing that we can test, and there's general testing in terms of like just making sure that ping pong, find nodes, nodes responses are functioning. And then as well exposing APIs. A lot of the stuff also just includes serving like information that comes just from the discovery B5 library. And so that's kind of the part that we are now stepping into is getting all that set up. Cool. Thank you so much. We have space for another question if there is anyone, any comments, any questions. Yeah. I mean, it's a very important topic right now because probably in like next year the 4.4s will ship, the Ethereum will drop its history. Veracruz is not coming anytime soon. So meanwhile, having light clients serving the state and serving the history is extremely important. And as we have diversity in the L1 clients, we need diversity in the portal clients. So yeah, I really respect the work, man. And if there are no more... Yeah, sorry. For serving the data, are you getting that from BASU? Like if you're resharing this chain state over the network, does that come from the BASU database? So that will eventually. But in terms of history right now, the portal network itself, history is being slowly propagated into the network, so that it can then be shared around. The state and beacon will eventually come, but as it stands, we're just trying to get history up and running and then that's kind of the points where we'll then focus on other things and then as well, where we kind of shift into actual, they're participating in the development of portal. Okay, thank you. Awesome, thank you so much, Derek.",
"eventId": "devcon-7",
- "slot_start": 1731572400000,
- "slot_end": 1731573000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1UYUaHo5Qavbvjs-V4IY1wgEZga3-zWvPCG7PXENX-k4"
+ "slot_start": 1731471300000,
+ "slot_end": 1731472200000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1V8MPOsuS_Y8NmrHqykkqj248dMqY5xfRkNholeY8m_Q",
+ "resources_slides": null,
+ "speakers": [
+ "derek-sorken"
+ ]
},
"vector": [
0,
@@ -645024,9 +643665,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -645036,6 +643674,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -645820,7 +644459,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -645858,6 +644496,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -645872,7 +644511,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -645896,7 +644534,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -646238,6 +644875,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -646337,10 +644975,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -646353,39 +644991,40 @@
},
{
"session": {
- "id": "running-ethereum-node-in-africa",
- "sourceId": "XT8ZWL",
- "title": "Running Ethereum Node In Africa",
- "description": "Running an Ethereum node in Africa presents both challenges and opportunities. It enables participation in the global blockchain ecosystem while contributing to network security and decentralization. Key points to highlight include overcoming infrastructure limitations, leveraging community support, the potential for economic empowerment through staking, and fostering local innovation and adoption. Emphasize the importance of education, collaboration, and strategic partnerships to",
- "track": "Real World Ethereum",
+ "id": "satellite-based-cryptographic-layer-extra-terrestial-extension-to-ethereum",
+ "sourceId": "SZBQLK",
+ "title": "Satellite based Cryptographic Layer - Extra-terrestial Extension to Ethereum",
+ "description": "Using nano-satellites with edge compute units we will show how we intend to build an orbital compute layer with unique properties. We will propose a novel cryptographic applications layer built with vision to space explorations.\r\n\r\nTypically public blockchains enable cryptographic primitives for the digital commons on earth, we will share novel implementation of cryptographic applications that will extend the digital commons into Low Earth Orbit (LEO) and import cryptographic resources from LEO.",
+ "track": "Cypherpunk & Privacy",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Stakers/Validators",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Geographical",
- "Diversity"
+ "space",
+ "frontier"
],
"tags": [
- "Home staking",
- "Distributed validator technology",
- "Decentralization",
- "diversity",
- "geographical",
- "Decentralization",
- "Distributed validator technology",
- "Home staking"
+ "Network State",
+ "Use cases of cryptography",
+ "DePIN",
+ "space",
+ "frontier",
+ "DePIN",
+ "Network State",
+ "Use cases of cryptography"
],
"language": "en",
"speakers": [
- "david-uzochukwu"
+ "daniel-bar",
+ "matej-yangwao"
],
"eventId": "devcon-7",
- "slot_start": 1731575400000,
- "slot_end": 1731576000000,
+ "slot_start": 1731648000000,
+ "slot_end": 1731648600000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1buMXIg1gOhRzKk22wUllHQbcl9xVPk1mQ7_JHDKF_oQ"
+ "resources_presentation": "https://docs.google.com/presentation/d/1Net_UwG69ncJlQvHg5qG_nefAW16HDrDDKf-9OaDpsw"
},
"vector": [
0,
@@ -646393,7 +645032,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -646789,8 +645427,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -646965,6 +645601,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -647160,11 +645798,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -647183,6 +645823,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -647226,7 +645867,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -647242,7 +645882,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -647605,8 +646244,6 @@
0,
0,
0,
- 0,
- 2,
2,
0,
0,
@@ -647700,18 +646337,17 @@
0,
0,
0,
- 0,
2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -647723,53 +646359,45 @@
},
{
"session": {
- "id": "running-wargames-to-prepare-protocol-teams-for-incident-response",
- "sourceId": "N3DBC3",
- "title": "Running Wargames to Prepare Protocol Teams for Incident Response",
- "description": "SEAL (Security Alliance) Wargames: cybersecurity exercises designed to enhance Web3 protocol resilience. We'll share experiences from running these with major Ethereum protocols, covering:\r\n-Exercise structure: OSINT, tabletops, and live simulations on forked networks\r\n-Scenario designs and common vulnerabilities\r\n-Infrastructure and open-source tooling\r\n-Key learnings and best practices\r\n-Scaling strategies and the importance of regular security drills in the evolving Web3 landscape",
- "track": "Security",
+ "id": "scalable-and-sovereign-evm-data-modern-data-engineering-best-practices",
+ "sourceId": "KEEUYL",
+ "title": "Scalable and sovereign EVM data: modern data engineering best practices",
+ "description": "Collecting and analyzing large historical EVM datasets can pose a significant challenge. This has led many teams and individuals to outsource their data infrastructure to commercial 3rd-party platforms. However, over the past year a new style of data workflow has emerged, using entirely open source software and local-first processing. This new ecosystem of tools allow anyone to cheaply, easily, and robustly collect and analyze any EVM dataset from the comfort of their own laptop.",
+ "track": "Developer Experience",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Product",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Coordination",
- "Security",
- "incident",
- "response",
- "Coordination",
- "Security"
- ],
"keywords": [
- "Incident",
- "Response"
+ "Data Engineering",
+ "Data Science",
+ "Data Analysis"
+ ],
+ "tags": [
+ "Developer Infrastructure",
+ "data",
+ "analysis",
+ "Developer",
+ "Infrastructure"
],
- "duration": 1350,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "mIOEkVh6aGM",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": "6732febd80d989c5b7b49fc9",
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732febd80d989c5b7b49fc9.vtt",
- "transcript_text": " And I also lead the War Games initiative for the Security Alliance. I'll give a brief introduction to just what the Security Alliance is and what the various initiatives are, because I think it's actually pretty relevant also after the first talk about ENS and data sharing. And so the top initiative here is actually called the SEAL-ISAC, which is not me, I'm SEAL-ISAC. This is the Information Security something something, which basically this is like a shared database between many different companies where they can share data on like DPRK threat actors or phishing data or bad domains. There's SEAL War Games, which is the initiative that I lead, where we prepare protocol teams for incident response through both tabletop simulations and then live simulations on forked environments. SEAL also operates SEAL 911, the emergency hotline, if your protocol is under attack or if you have discovered a vulnerability in a protocol and need to get in touch with a security expert as fast as possible. The Safe Harbor Agreement, which is legal protection if you're a white hat hacker and you're acting benevolently in an urgent situation to rescue funds from a protocol. Think Nomad Bridge hack a few years ago if you were trying to save money, but maybe you were worried because you thought that you'd be sued for hacking during because it'd be impossible to distinguish. The White Hat Safe Harbor Agreement exists to protect white hat hackers in those situations and a legal defense fund in case they sue you anyway. So today what we'll talk about primarily is war games. So what are these war games and why do we do them? I'll have some links to resources on how you can work with us. There's a lot of open source toolkits and we also run these as like a public good throughout the space. We'll be talking through some best practices that I've learned from working with some of the major protocols in the ecosystem and then just briefly show you what this new toolkit is that we released so you can run these yourself if you would like. So what are wargames? These are cybersecurity exercises for Web3. I've heard traditional cybersecurity folks call these something like a purple team exercise, where we're not exactly red team, blue team, but we're basically just trying to stress test these teams and understand how they behave under pressure. And so we want to help teams practice for these high-pressure situations before they actually happen. We want to be able to test both the technical side of their team and their social resilience. And we're not just trying to help cause them to panic, but we want them to practice emergency response. A lot of the reason why we started doing this was a few years ago. So the security lines was started by Sam Sun, and he was pulled into so many war rooms where it seemed like, I guess, from what I've heard, teams just completely melting down and not really being exactly prepared for what would happen. So what could we actually do to help put them in that situation before that inevitably happens? So war games take place through three phases. I do a lot of intelligence gathering, which really just means reading every document that the protocol's ever published, understand their contracts, understand how it works. We do a tabletop exercise where we talk through various scenarios with them and understand how they would have detected them, what they would do, who's in charge, and how would they have fixed something. And then what I think is the most fun is we do a live simulation. So we set up a forked environment, we run all of their contracts, we write all of their UIs, we run all of their monitoring, and then they actually have to coordinate in real time to defend and respond as if it was a real incident. And we tend to find a lot of things that they can improve through that process, and it also just helps the team build trust in each other so that they know when an incident goes down for real, I can trust my team to be there. So a big reason why we do this is because more and more hacks are due to operational failures, not smart contract bugs. That's a really, I think, good sign that we're making fewer and fewer dumb mistakes on the smart contract side. However, as all of the stuff that we're building is becoming such a critical component of global financial infrastructure, the stakes are higher to actually operationally be strong as well. And so whether that's things like supply chain attacks or social engineering, it's much harder now than just not including dumb bugs in your smart contracts. So these are cross-functional exercises. We're not just working with the development team. They're of course a core part of it, but we're also tending to work with their auditors if they're a big protocol that has a guardian multi-sig that's in charge of pausing the protocol in case of emergency. We of course work with them. Communications team is actually essential so that we know what would they be communicating out to the public and when during an incident and legal so that they can say, okay, if we were to take this action perhaps to protect the users of our protocol, can we do that? Should we do that? And what should we be saying? The conversations between communications, legal, and devs should really be things that are figured out in advance so that during the incident,'re not thinking like do we tweet out that we're under attack right now or do we say something cryptic or what do we say like these are things that you can just have in a playbook so that you don't have to think about it in the moment. We've worked with a number of products of protocols so far but the purpose of this slide is also just to show you like why teams are working with us, it's because teams are growing. These are global teams, and it's really hard to prepare for this type of thing. There's many ways to engage with us. If you're a protocol that wants to work with a security alliance and have a drill performed with you, there's a form on the website, and there's also open source resources for you to be able to run these yourself. So this is a quote that I had a really hard time attributing. The internet said it was either like a Greek poet or the Navy Seals, but I think that it really like stands to to show like why we do this and it's that under pressure we don't rise to the occasion, we sink to our level of training. Yeah I think that that speaks to why we do this. So each one of these builds is quite different. A lot of protocols have various sorts of custom infrastructure and monitoring. So every time we do this, we end up having to build a lot of things. And we've tried to combine all of those tools and things that we've learned on how to run these simulations into this drill template that you can see here. It's on the Security Alliance GitHub repository. But what are the things that we do to make the environment feel realistic? So we of course have to run a network fork. We're usually either doing that with Anvil or with Tenderly. We have to run a block explorer, so we're either running Block Scout or using a virtual test net. We're running monitoring, so it's essential to mirror the same monitoring that you would have on main net.",
- "eventId": "devcon-7",
- "slot_start": 1731390600000,
- "slot_end": 1731392400000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1Vl9aDLrFn0_bNTA3ddPbHqxDjrCLUyNEIUn4eBlSNzE",
- "resources_slides": null,
"speakers": [
- "isaac-patka",
- "kelsie-nabben"
- ]
+ "storm-slivkoff"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731573000000,
+ "slot_end": 1731574800000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ArYtVYufUwHpFKb-cm8W6DCWGSPca78nUlpjKQDTmiY"
},
"vector": [
- 6,
0,
0,
0,
+ 6,
+ 0,
+ 0,
0,
0,
0,
@@ -648159,6 +646787,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -648342,8 +646971,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -648568,6 +647195,13 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -648673,7 +647307,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -648818,6 +647451,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -648963,32 +647604,14 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 2,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 2,
0,
0,
0,
@@ -649083,11 +647706,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -649101,41 +647724,34 @@
},
{
"session": {
- "id": "samba-a-besu-portal-client",
- "sourceId": "FTC8PQ",
- "title": "Samba, a Besu Portal Client",
- "description": "A presentation about my experience participating in the EPF. Talking primarily about the project I worked on for the cohort and various obstacles that I faced along the way. I additionally aim to go into detail about where I see Samba going in the future and my role in that development.",
- "track": "[CLS] EPF Day",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Developer",
+ "id": "scalable-multi-party-fhe-with-phantom-zone",
+ "sourceId": "SLJ9QS",
+ "title": "Scalable multi-party FHE with Phantom-zone",
+ "description": "The talk introduces \"phantom-zone\", a framework to write scalable consumer facing MPC apps using multi-party FHE. Starting with what's multi-party FHE, talk gives a demo of non-trivial MPC app. Followed by introduction to programming model of MPC apps using multi-party FHE inside phantom-zone. Then the talk dives deep into primitives to realise multi-party FHE and ends with advanced FHE gadgets that further enhance multi-party FHE.",
+ "track": "Applied Cryptography",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Portal",
- "network"
- ],
"keywords": [
- "EPF"
+ "FHE",
+ "MP-FHE"
+ ],
+ "tags": [
+ "MPC",
+ "mp-fhe",
+ "MPC"
],
- "duration": 705,
"language": "en",
- "sources_swarmHash": "e02934d00bab1d926fea5b2862138be2ad9176107861f2ad27b01d9f661df389",
- "sources_youtubeId": "g9P0Lu2qqnI",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67342b249dbb7a90e1bd5b22.vtt",
- "transcript_text": " . All right. Yes. So I am Derek. Unfortunately, my partner Meltson wasn't able to make it. But yeah, our joint project is Bezu portal client, Samba. So. Yes, so I guess I'll give a brief introduction to Portal, because I think a lot of the reasons that I wanted to work on this project were just because I found Portal to be such an interesting topic. And so, there we go. So for the purposes of SOMB up to the scope of EPF, which is just for a few main roles through the history subnetwork. Portal network provides a solution to the proposed changes in EIP-44s that allows for the drastic limiting of storage requirements to run a node. As well, it also provides a way to handle the sharing of data in a way that not only can handle scaling, but actually benefits from scaling. And these benefits also directly link to Ethereum usability in lowering the barrier of entry to participation in the Ethereum ecosystem. And then as well, outside of the scope of EPF, as we continue, Portal also contains proposed solutions to managing state and beacon chain-related information, although this is somewhat more preliminary. Oh, there we go. And so now moving into the role of Samba in Portal, although this is somewhat more preliminary. There we go. Now moving into the role of Samba in Portal. There we go. So there's kind of two main roles Samba can play in this big kind of puzzle. One of the big roles is, of course, to fill the gap in the consensus hyperledger ecosystem in terms of a long-term EIP-4IP44 solution in regard to the existence of Samba. This also works to increase the portal client diversity in addition to ease of use in terms of the base of execution clients. But I think the other one and potentially more exciting in my eyes is its unique position compared to other portal clients in that it has a way to easily bring portal functionality to different Android, to the Android ecosystem with the benefit of the inherent modularity of Java, but also its native support. And so it's a very realistic goal to expect that Samba could simply be built on top of, as a library for other mobile or resource constrained applications. And so, moving into where Samba is at right now, my initial proposal at the beginning was extremely ambitious, and I admit that obviously not quite where we got to, but essentially this proposal is a model of where Samba will be at one point. And so all communications and related infrastructure, including disk B5, portal wire, and UTP, are eventually going to be implemented, mainly UTP at this point, it's the one that we're working on. And then to have a fully functioning history network, as well as full function of state beacon, state and beacon to the point of present portal development, as well as full interoperability with other portal clients. And so our updated goal range, of course, for the scope of EPF up to this point just pertains to what we figured would be reasonable in this time scope, but essentially that's to get, to have had primary communication infrastructure including a Discovery V5 and then the portal wire. Unfortunately, UTP was a big setback in the sense that there is no generalized UTP library, and so unfortunately we're not able to piggyback off anything like that and will have to be something that we sit down and do ourselves. And then to have infrastructure in place where history network function. And so then moving on, once we have that infrastructure and that we have is to have generalized internal testing, we wanted to have SSD sterilization, deserialization, exposed API infrastructure, metrics. And the only thing on the list that we weren't quite able to achieve in this goal range is portal hive testing. Unfortunately, just given the scope, we are very close to having had it. A lot of it was just putting little pieces together to test it, but we figured it'd be better to just add more functionality before we go and add just small pieces of testing, as opposed to now we can, as we go forward, add a lot more tests and then prove that we can then interop with other clients. And so this is a general diagram of kind of how Samba functions and the layout of Samba. And the big two pieces on the bottom here are the ones that really took the brunt of the time is getting all the base protocol communication systems in place. And so that includes like inbound, outbound communication. Whether that be coming from a client, there's a different way to handle requests coming in as opposed to sending out requests or then receiving inbound requests or responses and vice versa. But then of course there's other pieces of the puzzle such as the API which Meltzun had done in Expose an API. So we're very well set up to then start actually serving different pieces, such as the disk v5 and history, portal history APIs. And so, moving forward in the project, the future of Samba, obviously the development of Samba does not stop with EPF. The project is in a very good place infrastructure-wise and has achieved a lot of milestones in terms of functionality. Like at this point currently, we are able to send and receive all different types, all the available portal wire packets to all the other portal clients. And in terms of certain packet types, such as ping pong, obviously work well. And then we are able to now up to this point almost full functionality on just sending and receiving nodes in terms of building our peers. And so moving forward then the continued development will eventually bring us up to date with the other portal clients. And so that is, to me, also an exciting part of being a part of Portal is that for the development of Samba, we have EPF. But then also, moving after EPF, there's a portion of getting fully caught up to other portal clients. But then in terms of, I guess, my experience, it's also very exciting in that once we get to that point, it's an entirely different development paradigm where instead of catching up and following different specs, it's now actively participating in development. And so this development is much more something that I will have to learn as well, and that kind of brings me to, I would like to talk a bit about my EPF experience, because I think that was a really big part of this program for me, is just a lot of the learning that I've done. And so I think for me, there's definitely too many skills to list here. But if I were to sum it up, EPF was my introduction to Ethereum. Before EPF, I didn't know what Ethereum was. I didn't even know what blockchain technology was. So for me, that was a huge, just to get into the space and learn everything. And of course, that brought a huge confidence boost in terms of development. I previously, you know, I've never worked on such a large-scale project before. And so those organizational skills that are required to create that project was huge to me, and definitely gives me a lot more confidence moving forward in terms of developing projects and continuing to work on this project. As well, I think I acquired a lot of new learning skills. For me, I think I could best describe it as I learned how to learn. So I guess the biggest example for, in my case, is going through and learning the consensus discovery of V5 library. I had never had such a large scale library that I had to learn in the past. And so learning this library and then automatically going over to the Techu library and then learning the SSC internal infrastructure was a way to then quickly apply the skills that I just learned to then learn a new library, which was a really great experience. And as well, it gave me a project I really enjoy working on and of course will continue working on. And so yeah, the Samba repository can be found onelson's GitHub. I hope that one day we can have a hyperledger or consensus repository for that name. And then of course, I'd like to give a big thank you to Melson, unfortunately he wasn't able to be here, but he's been a great partner, great working with you Melson if you're watching. And then my friend and mentor, Colby. So unfortunately I can't say that to Colby. If you're interested more in Portal, his talk is going on, I believe, on stage two right now. And then, of course, EPF organizers, Josh and Mario. It's been a really great experience. I really thank you for this. But yeah, thank you. Thank you so much, Derek. I really appreciate it. I really appreciate your words and also your experience with EPF. It's amazing to see. I'm also going to make it. I met him in Argentina a week ago. He's also a great person. Couldn't come, but he will be still also contributing to Samba. Anyone has a question about Portal, about the best Java implementation, yeah. Yeah, just kind of a general question, like if you're still working on UTP, how are you doing the interop testing to verify correctness with the other portal clients? So for interop testing, there's a lot more than just actual content sharing testing, like for example, just the propagation of peers is one thing that we can test, and there's general testing in terms of like just making sure that ping pong, find nodes, nodes responses are functioning. And then as well exposing APIs. A lot of the stuff also just includes serving like information that comes just from the discovery B5 library. And so that's kind of the part that we are now stepping into is getting all that set up. Cool. Thank you so much. We have space for another question if there is anyone, any comments, any questions. Yeah. I mean, it's a very important topic right now because probably in like next year the 4.4s will ship, the Ethereum will drop its history. Veracruz is not coming anytime soon. So meanwhile, having light clients serving the state and serving the history is extremely important. And as we have diversity in the L1 clients, we need diversity in the portal clients. So yeah, I really respect the work, man. And if there are no more... Yeah, sorry. For serving the data, are you getting that from BASU? Like if you're resharing this chain state over the network, does that come from the BASU database? So that will eventually. But in terms of history right now, the portal network itself, history is being slowly propagated into the network, so that it can then be shared around. The state and beacon will eventually come, but as it stands, we're just trying to get history up and running and then that's kind of the points where we'll then focus on other things and then as well, where we kind of shift into actual, they're participating in the development of portal. Okay, thank you. Awesome, thank you so much, Derek.",
- "eventId": "devcon-7",
- "slot_start": 1731471300000,
- "slot_end": 1731472200000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1V8MPOsuS_Y8NmrHqykkqj248dMqY5xfRkNholeY8m_Q",
- "resources_slides": null,
"speakers": [
- "derek-sorken"
- ]
+ "janmajaya-mall"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731567600000,
+ "slot_end": 1731569400000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1V86Kc6aOcbAUsOm8NBUDaQ00YrCn0XJN5ce8Lyt73WU"
},
"vector": [
0,
@@ -649148,14 +647764,12 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -649558,6 +648172,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -649716,7 +648331,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -650451,13 +649065,12 @@
0,
0,
0,
- 2,
- 0,
0,
+ 2,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -650473,40 +649086,37 @@
},
{
"session": {
- "id": "satellite-based-cryptographic-layer-extra-terrestial-extension-to-ethereum",
- "sourceId": "SZBQLK",
- "title": "Satellite based Cryptographic Layer - Extra-terrestial Extension to Ethereum",
- "description": "Using nano-satellites with edge compute units we will show how we intend to build an orbital compute layer with unique properties. We will propose a novel cryptographic applications layer built with vision to space explorations.\r\n\r\nTypically public blockchains enable cryptographic primitives for the digital commons on earth, we will share novel implementation of cryptographic applications that will extend the digital commons into Low Earth Orbit (LEO) and import cryptographic resources from LEO.",
- "track": "Cypherpunk & Privacy",
- "type": "Lightning Talk",
+ "id": "scaling-autonomous-worlds-building-the-foundations-and-sewers-for-millions-of-inhabitants",
+ "sourceId": "QPAXL7",
+ "title": "Scaling autonomous worlds - building the foundations… and sewers for millions of inhabitants",
+ "description": "One tends to think of Ethereum scaling in financial terms—how many transactions per second? What’s the TVL? How much liquidity?\r\n\r\nBut in a possible future where Ethereum applications extend beyond finance, into areas like autonomous worlds, games, and social, what does scaling look like and what challenges await?\r\n\r\nJoin us as we explore challenges, solutions, and open questions in this space—how do we bring latency down despite seconds-long block time? Could we shard an app across multiple chains?",
+ "track": "Layer 2",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "space",
- "frontier"
+ "Cross-chain"
],
"tags": [
- "Network State",
- "Use cases of cryptography",
- "DePIN",
- "space",
- "frontier",
- "DePIN",
- "Network State",
- "Use cases of cryptography"
+ "Layer 2s",
+ "Cross-L2",
+ "Autonomous World",
+ "cross-chain",
+ "Autonomous World",
+ "Cross-L2",
+ "Layer 2s"
],
"language": "en",
"speakers": [
- "daniel-bar",
- "matej-yangwao"
+ "tdot"
],
"eventId": "devcon-7",
- "slot_start": 1731648000000,
- "slot_end": 1731648600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Net_UwG69ncJlQvHg5qG_nefAW16HDrDDKf-9OaDpsw"
+ "slot_start": 1731484800000,
+ "slot_end": 1731486600000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/11DTfplHre4QguicqcET5ubMdfycNHdyjo8Imn5A0lWc"
},
"vector": [
0,
@@ -650514,9 +649124,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -651085,11 +649695,10 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -651283,13 +649892,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -651308,7 +649915,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -651328,6 +649934,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -651371,6 +649978,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -651394,7 +650002,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -651461,6 +650068,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -651821,12 +650429,10 @@
0,
0,
0,
- 0,
2,
0,
0,
0,
- 0,
2,
0,
0,
@@ -651839,48 +650445,39 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "scalable-and-sovereign-evm-data-modern-data-engineering-best-practices",
- "sourceId": "KEEUYL",
- "title": "Scalable and sovereign EVM data: modern data engineering best practices",
- "description": "Collecting and analyzing large historical EVM datasets can pose a significant challenge. This has led many teams and individuals to outsource their data infrastructure to commercial 3rd-party platforms. However, over the past year a new style of data workflow has emerged, using entirely open source software and local-first processing. This new ecosystem of tools allow anyone to cheaply, easily, and robustly collect and analyze any EVM dataset from the comfort of their own laptop.",
- "track": "Developer Experience",
- "type": "Talk",
- "expertise": "Intermediate",
+ "id": "scaling-clean-air-now-and-the-future",
+ "sourceId": "RKA9MF",
+ "title": "Scaling Clean Air: Now and the Future",
+ "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Data Engineering",
- "Data Science",
- "Data Analysis"
- ],
- "tags": [
- "Developer Infrastructure",
- "data",
- "analysis",
- "Developer",
- "Infrastructure"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
"speakers": [
- "storm-slivkoff"
+ "louis-goessling"
],
"eventId": "devcon-7",
- "slot_start": 1731573000000,
- "slot_end": 1731574800000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1ArYtVYufUwHpFKb-cm8W6DCWGSPca78nUlpjKQDTmiY"
+ "slot_start": 1731570600000,
+ "slot_end": 1731571500000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ZJZJ_2zvDgnrKFG8JEZo8VMp_Z1mb0btmMRtR2j0Vv0"
},
"vector": [
0,
+ 6,
0,
0,
- 6,
0,
0,
0,
@@ -652273,7 +650870,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -652455,6 +651051,71 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -652633,7 +651294,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -652683,7 +651343,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -652940,7 +651599,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -653101,69 +651759,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -653193,7 +651788,6 @@
2,
0,
0,
- 0,
2,
0,
0,
@@ -653212,39 +651806,55 @@
},
{
"session": {
- "id": "scalable-multi-party-fhe-with-phantom-zone",
- "sourceId": "SLJ9QS",
- "title": "Scalable multi-party FHE with Phantom-zone",
- "description": "The talk introduces \"phantom-zone\", a framework to write scalable consumer facing MPC apps using multi-party FHE. Starting with what's multi-party FHE, talk gives a demo of non-trivial MPC app. Followed by introduction to programming model of MPC apps using multi-party FHE inside phantom-zone. Then the talk dives deep into primitives to realise multi-party FHE and ends with advanced FHE gadgets that further enhance multi-party FHE.",
- "track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "id": "scaling-community-lessons-from-building-base",
+ "sourceId": "P73W8S",
+ "title": "Scaling Community: Lessons from Building Base",
+ "description": "Drawing from experiences as a Base core contributor and Base community lead, this talk is about building scalable Ethereum communities. Learn strategies for engagement, growth, best practices, and key insights.",
+ "track": "Developer Experience",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "FHE",
- "MP-FHE"
- ],
"tags": [
- "MPC",
- "mp-fhe",
- "MPC"
+ "Security",
+ "community",
+ "Layer 1",
+ "Layer 2s",
+ "Values"
],
- "language": "en",
- "speakers": [
- "janmajaya-mall"
+ "keywords": [
+ "Community",
+ "Discord",
+ "Farcaster",
+ "Building Community",
+ "Community Management",
+ "Community Security"
],
+ "duration": 574,
+ "language": "en",
+ "sources_swarmHash": "4e8c46194a8800b5909aeb01cc6c0324728e82519f7c0ad031cb1149411d564e",
+ "sources_youtubeId": "7T9YaSIAk2s",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67331c173a168eb535311ae1.vtt",
+ "transcript_text": " Tanya Cushman Reviewer Reviewer Hey everybody. Can everybody hear me okay? Pretty good? Alright. Thank you so much for coming here and being here today. So, hello friends. My name is Will Binz. I also go by W Binns. They're smashing my name together. I lead communities at Base. I'm also a full stack developer at Base. We're one and a half year old, layer two on top of Ethereum. Our objective is to build a global open economy that spreads equality, opportunity, and freedom around the world. We just processed our one billionth transaction this past week. It's still day one. And across Discord, Farcaster, GitHub, and X. There's millions of people that are part of our communities. I said hello friends, but we don't know each other. We're different genders, different skin colors. We come from different countries. There's all kinds of things that make us different here, that fracture us, that drive us apart, that lead to a lot of the conflict that we see in this world right now. But we're here. We're here together. All of us here left something behind that really wasn't working so well in some way. To look towards something better for us, for our friends, for our families, for our loved ones. And that, I think, is something that all of us can build a friendship on. And I think that's, in the context of this lightning talk, high level, our future is the most important part, focusing on that in building a scalable community. An open economy that anybody can be part of. Being able to work from wherever you want. Being able to live where you want, equality, all those things I talked about, all those things that make us different, all those things that don't matter, transparency, verifiability on chain, not having to take each other's word for things, freedom, and hopefully, in what we see these days in the future, more peace in the world. But how do we do that? We have to make space for everyone. Builders, creators, lurkers, people that are just curious, speculators, gamers, even scammers and spammers. There should be direct paths for all of these people. And in order to do that, we have to create opportunities for everyone. I just said scammers and spammers. And I think one of the most important parts of creating opportunity for scammers and spammers is being empathetic. There's people that are born just by the lottery of life in some part of the world where they can't even leave their town. They wish that they could get on a plane to come somewhere like this, to sit next to us today, but they can't do that. The opportunities in front of them led them to that path. It's up to us as community builders to build something better, to help people discover new apps, new opportunities, new jobs, learn, educate them. For some people, it's just to make friends, new friends, in a real world where they don't have any. And in all that, all of us, a better life. In order to do that, we have to focus on the fact that these problems in the world, these problems that we have with each other, across this EVM even, these things that make us different, these sub-communities that split us apart, that we see disagreements in, those problems are what unite us. They're not what should drive us apart. This EVM, Ethereum, is what connects us together. And so you as builders, building community, people, building apps across the EVM, across on-chain, an app is just something people download, but a community is something that you come back for. So what do we do? We have to realize and admit our mistakes when we have them. We have to realize we're not kings and queens. We're not royalty. Being in this space is a gift from the universe. But it's also a challenge. What am I? What are we? What are you going to do with this gift to be here today? To be able to fly here to Thailand. To be part of this community when others can't leave their own. To build something better. And there's a quote that's often cliche, but it's so true. Alone, we go fast, but together, we can go far. And so in that vein, I set up just a Telegram group. So anybody here, there's no difference in networks. We're all part of this Ethereum community. If you'd like to be part of this telegram, I'm an open book. People in our base community are open books. We're trying to build a better world together. Let's share our knowledge. Let's build a brain test. People watching this recording later, come to this group. Let's work together. Let's go through the things that we can't talk about in a lightning talk. How do we build safe, secure communities? How do we scale communities? How do we make sure that everybody has their space? So thank you all for sharing your time to be here today. Thank you so much, Will. Thank so much Will. Any questions? Please raise your hand I will throw this cube to you. Oh there's one there? Please help me. It's not a question, but a word of gratitude. Thank you for your talk. Thank you for your time. We highly need this kind of speech in the space like that. I just went out from a very different conversation. Respect. Thank you. Yeah. Thank you. Thank you. I see another question over there. Hi, Will. I saw you in person. How do you see communities like base Latin, base India, base Africa impact those communities? I think that thinking about like how all communities start, they start small. And in time, they grow. Some succeed, some fail, but if we think of things like on a cellular level, how human life imitates itself in the form of how we build communities, the ones that continue to get bigger and bigger and bigger, they divide and become their own communities. Taking Costa Rica as an example here, there's many builders in Costa Rica as an example here. There's many builders in Costa Rica, but in that, there's also many people with differences. There's people that want to build on chain, that just want to play games, they just want to trade, they just want to work on infra. And a lot of those people, they don't want to have anything to do with each other. That doesn't mean they don't like each other, they're just not interested. So for us as community builders, it's important that within the first 10, 15 seconds when they come into our community, we're helping them get to the right place. And so in the context of this question for based LATAM, which we're referring to here, which is based communities in Latin America, it's continuing to build more and more smaller and smaller and smaller communities until eventually we reach the grassroots. So that's my answer to the question.",
"eventId": "devcon-7",
- "slot_start": 1731567600000,
- "slot_end": 1731569400000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1V86Kc6aOcbAUsOm8NBUDaQ00YrCn0XJN5ce8Lyt73WU"
+ "slot_start": 1731401400000,
+ "slot_end": 1731402000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Z6KNA8npIjlvXcTWwPrFhWHFQ9A2gd2wkiaNRb-bwuQ",
+ "resources_slides": null,
+ "speakers": [
+ "wbnns"
+ ]
},
"vector": [
0,
0,
0,
+ 6,
0,
0,
0,
@@ -653252,8 +651862,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -653661,7 +652269,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -653822,6 +652429,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -653992,6 +652600,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -654006,6 +652615,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -654056,6 +652666,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -654083,7 +652694,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -654114,6 +652724,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -654165,6 +652776,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -654468,7 +653080,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -654550,6 +653161,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -654557,7 +653169,6 @@
0,
0,
0,
- 2,
0,
2,
0,
@@ -654567,47 +653178,44 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "scaling-autonomous-worlds-building-the-foundations-and-sewers-for-millions-of-inhabitants",
- "sourceId": "QPAXL7",
- "title": "Scaling autonomous worlds - building the foundations… and sewers for millions of inhabitants",
- "description": "One tends to think of Ethereum scaling in financial terms—how many transactions per second? What’s the TVL? How much liquidity?\r\n\r\nBut in a possible future where Ethereum applications extend beyond finance, into areas like autonomous worlds, games, and social, what does scaling look like and what challenges await?\r\n\r\nJoin us as we explore challenges, solutions, and open questions in this space—how do we bring latency down despite seconds-long block time? Could we shard an app across multiple chains?",
- "track": "Layer 2",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "scaling-crypto-theres-an-app-for-that-onboarding-millions-in-africa-with-minipay",
+ "sourceId": "EXCPST",
+ "title": "Scaling Crypto? There's an App for That. Onboarding Millions in Africa with MiniPay",
+ "description": "Post-EthCC, everyone’s talking about the industry’s influx of infra & lack of consumer apps. These conversations overlook the strides made in Africa with MiniPay, a self-custodial stablecoin wallet with 3M+ activated accounts since launching less than a year ago. In this panel, Rene, Yoseph & co-panelists will discuss building, scaling, & updating a truly user-friendly crypto wallet, introducing net new users to Web3 and dApps, & the power of ERC-20 stablecoins for payments in emerging markets.",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Cross-chain"
+ "payment",
+ "p2p finance",
+ "mobile"
],
"tags": [
- "Layer 2s",
- "Cross-L2",
- "Autonomous World",
- "cross-chain",
- "Autonomous World",
- "Cross-L2",
- "Layer 2s"
+ "Protocol Design",
+ "Scalability",
+ "UI/UX",
+ "Mobile",
+ "Protocol Design",
+ "Scalability",
+ "UI/UX"
],
"language": "en",
"speakers": [
- "tdot"
+ "rene-reinsberg"
],
"eventId": "devcon-7",
- "slot_start": 1731484800000,
- "slot_end": 1731486600000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/11DTfplHre4QguicqcET5ubMdfycNHdyjo8Imn5A0lWc"
+ "slot_start": 1731574800000,
+ "slot_end": 1731575400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1lk319WDhop2qBsR_BdMLAl1tdzOwri17ao4IPguI7Ac"
},
"vector": [
0,
@@ -654616,7 +653224,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -655190,7 +653797,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -655384,6 +653990,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -655406,6 +654013,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -655418,6 +654026,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -655428,9 +654037,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -655472,7 +654078,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -655502,6 +654107,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -655562,7 +654168,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -655837,7 +654442,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -655923,7 +654527,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -655933,6 +654536,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -655945,36 +654550,50 @@
},
{
"session": {
- "id": "scaling-clean-air-now-and-the-future",
- "sourceId": "RKA9MF",
- "title": "Scaling Clean Air: Now and the Future",
- "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "",
- "audience": "Engineering",
+ "id": "scaling-ethereum-with-das-an-iterative-approach",
+ "sourceId": "JFWPRG",
+ "title": "Scaling Ethereum with DAS: an iterative approach",
+ "description": "In this time between the launch of 4844 and the possible launch of a first version of PeerDAS, we explore and explain the iterative approach that has been employed in the rollout of blobs and DAS to Ethereum, and discuss the past and future steps.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
- "language": "en",
- "speakers": [
- "louis-goessling"
+ "tags": [
+ "Blobspace",
+ "Data Availability",
+ "Ethereum Roadmap",
+ "Scalability"
+ ],
+ "keywords": [
+ "PeerDAS"
],
+ "duration": 1522,
+ "language": "en",
+ "sources_swarmHash": "567a45d310dc81275e061b69797f55ce5386ac2d95acdaf5d71076c274539d71",
+ "sources_youtubeId": "toR2UKzE_zA",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731570600000,
- "slot_end": 1731571500000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1ZJZJ_2zvDgnrKFG8JEZo8VMp_Z1mb0btmMRtR2j0Vv0"
+ "slot_start": 1731398400000,
+ "slot_end": 1731400200000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1AIOGsICQD3wWyrBZ5kDP7FX-hHDQ53lT_n8M7Jdl_kI",
+ "resources_slides": null,
+ "speakers": [
+ "francesco"
+ ]
},
"vector": [
- 0,
- 6,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -656786,8 +655405,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -656857,6 +655478,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -656908,6 +655530,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -657276,15 +655899,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 0,
- 0,
- 2,
- 0,
- 0,
2,
0,
0,
@@ -657297,58 +655916,48 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "scaling-community-lessons-from-building-base",
- "sourceId": "P73W8S",
- "title": "Scaling Community: Lessons from Building Base",
- "description": "Drawing from experiences as a Base core contributor and Base community lead, this talk is about building scalable Ethereum communities. Learn strategies for engagement, growth, best practices, and key insights.",
- "track": "Developer Experience",
+ "id": "searcher-competition-in-block-building",
+ "sourceId": "MHRYV9",
+ "title": "Searcher Competition in Block Building",
+ "description": "We study the amount of MEV captured by validators, as a function of searcher competition. The core is a suitable solution concept in this context that makes robust predictions independent of implementation details or specific mechanisms chosen. The surplus share of validators is a function of searcher competition. Searchers can obtain at most the marginal value increase of the winning block relative to the best block that can be built without them. We validate the theory empirically.",
+ "track": "Cryptoeconomics",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Design",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Security",
- "community",
- "Layer 1",
- "Layer 2s",
- "Values"
- ],
"keywords": [
- "Community",
- "Discord",
- "Farcaster",
- "Building Community",
- "Community Management",
- "Community Security"
+ "Cooperative",
+ "Game",
+ "Theory;"
+ ],
+ "tags": [
+ "Core Protocol",
+ "Gaming",
+ "Mechanism design",
+ "MEV",
+ "theory",
+ "cooperative",
+ "Core Protocol",
+ "Mechanism design",
+ "MEV"
],
- "duration": 574,
"language": "en",
- "sources_swarmHash": "4e8c46194a8800b5909aeb01cc6c0324728e82519f7c0ad031cb1149411d564e",
- "sources_youtubeId": "7T9YaSIAk2s",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67331c173a168eb535311ae1.vtt",
- "transcript_text": " Tanya Cushman Reviewer Reviewer Hey everybody. Can everybody hear me okay? Pretty good? Alright. Thank you so much for coming here and being here today. So, hello friends. My name is Will Binz. I also go by W Binns. They're smashing my name together. I lead communities at Base. I'm also a full stack developer at Base. We're one and a half year old, layer two on top of Ethereum. Our objective is to build a global open economy that spreads equality, opportunity, and freedom around the world. We just processed our one billionth transaction this past week. It's still day one. And across Discord, Farcaster, GitHub, and X. There's millions of people that are part of our communities. I said hello friends, but we don't know each other. We're different genders, different skin colors. We come from different countries. There's all kinds of things that make us different here, that fracture us, that drive us apart, that lead to a lot of the conflict that we see in this world right now. But we're here. We're here together. All of us here left something behind that really wasn't working so well in some way. To look towards something better for us, for our friends, for our families, for our loved ones. And that, I think, is something that all of us can build a friendship on. And I think that's, in the context of this lightning talk, high level, our future is the most important part, focusing on that in building a scalable community. An open economy that anybody can be part of. Being able to work from wherever you want. Being able to live where you want, equality, all those things I talked about, all those things that make us different, all those things that don't matter, transparency, verifiability on chain, not having to take each other's word for things, freedom, and hopefully, in what we see these days in the future, more peace in the world. But how do we do that? We have to make space for everyone. Builders, creators, lurkers, people that are just curious, speculators, gamers, even scammers and spammers. There should be direct paths for all of these people. And in order to do that, we have to create opportunities for everyone. I just said scammers and spammers. And I think one of the most important parts of creating opportunity for scammers and spammers is being empathetic. There's people that are born just by the lottery of life in some part of the world where they can't even leave their town. They wish that they could get on a plane to come somewhere like this, to sit next to us today, but they can't do that. The opportunities in front of them led them to that path. It's up to us as community builders to build something better, to help people discover new apps, new opportunities, new jobs, learn, educate them. For some people, it's just to make friends, new friends, in a real world where they don't have any. And in all that, all of us, a better life. In order to do that, we have to focus on the fact that these problems in the world, these problems that we have with each other, across this EVM even, these things that make us different, these sub-communities that split us apart, that we see disagreements in, those problems are what unite us. They're not what should drive us apart. This EVM, Ethereum, is what connects us together. And so you as builders, building community, people, building apps across the EVM, across on-chain, an app is just something people download, but a community is something that you come back for. So what do we do? We have to realize and admit our mistakes when we have them. We have to realize we're not kings and queens. We're not royalty. Being in this space is a gift from the universe. But it's also a challenge. What am I? What are we? What are you going to do with this gift to be here today? To be able to fly here to Thailand. To be part of this community when others can't leave their own. To build something better. And there's a quote that's often cliche, but it's so true. Alone, we go fast, but together, we can go far. And so in that vein, I set up just a Telegram group. So anybody here, there's no difference in networks. We're all part of this Ethereum community. If you'd like to be part of this telegram, I'm an open book. People in our base community are open books. We're trying to build a better world together. Let's share our knowledge. Let's build a brain test. People watching this recording later, come to this group. Let's work together. Let's go through the things that we can't talk about in a lightning talk. How do we build safe, secure communities? How do we scale communities? How do we make sure that everybody has their space? So thank you all for sharing your time to be here today. Thank you so much, Will. Thank so much Will. Any questions? Please raise your hand I will throw this cube to you. Oh there's one there? Please help me. It's not a question, but a word of gratitude. Thank you for your talk. Thank you for your time. We highly need this kind of speech in the space like that. I just went out from a very different conversation. Respect. Thank you. Yeah. Thank you. Thank you. I see another question over there. Hi, Will. I saw you in person. How do you see communities like base Latin, base India, base Africa impact those communities? I think that thinking about like how all communities start, they start small. And in time, they grow. Some succeed, some fail, but if we think of things like on a cellular level, how human life imitates itself in the form of how we build communities, the ones that continue to get bigger and bigger and bigger, they divide and become their own communities. Taking Costa Rica as an example here, there's many builders in Costa Rica as an example here. There's many builders in Costa Rica, but in that, there's also many people with differences. There's people that want to build on chain, that just want to play games, they just want to trade, they just want to work on infra. And a lot of those people, they don't want to have anything to do with each other. That doesn't mean they don't like each other, they're just not interested. So for us as community builders, it's important that within the first 10, 15 seconds when they come into our community, we're helping them get to the right place. And so in the context of this question for based LATAM, which we're referring to here, which is based communities in Latin America, it's continuing to build more and more smaller and smaller and smaller communities until eventually we reach the grassroots. So that's my answer to the question.",
- "eventId": "devcon-7",
- "slot_start": 1731401400000,
- "slot_end": 1731402000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Z6KNA8npIjlvXcTWwPrFhWHFQ9A2gd2wkiaNRb-bwuQ",
- "resources_slides": null,
"speakers": [
- "wbnns"
- ]
+ "akaki-mamageishvili"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731648600000,
+ "slot_end": 1731649200000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1oRDP1vAH4P88oiBLEXOsJco7KgtJbQmYvKAeAkMug6Y"
},
"vector": [
- 0,
0,
0,
6,
@@ -657791,6 +656400,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -657931,7 +656541,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -658105,6 +656714,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -658115,11 +656725,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
+ 2,
0,
0,
0,
@@ -658166,7 +656773,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -658212,6 +656818,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -658224,7 +656831,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -658276,7 +656882,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -658548,6 +657153,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -658574,6 +657180,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -658670,52 +657277,40 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0
]
},
{
"session": {
- "id": "scaling-crypto-theres-an-app-for-that-onboarding-millions-in-africa-with-minipay",
- "sourceId": "EXCPST",
- "title": "Scaling Crypto? There's an App for That. Onboarding Millions in Africa with MiniPay",
- "description": "Post-EthCC, everyone’s talking about the industry’s influx of infra & lack of consumer apps. These conversations overlook the strides made in Africa with MiniPay, a self-custodial stablecoin wallet with 3M+ activated accounts since launching less than a year ago. In this panel, Rene, Yoseph & co-panelists will discuss building, scaling, & updating a truly user-friendly crypto wallet, introducing net new users to Web3 and dApps, & the power of ERC-20 stablecoins for payments in emerging markets.",
+ "id": "secondhand-liberalism-a-story-of-microdosing-internet-freedom",
+ "sourceId": "TB8DG7",
+ "title": "Secondhand Liberalism: A Story of Microdosing Internet Freedom",
+ "description": "Liberalism isn't the default. For those growing up in non-Western societies, liberalism is often \"secondhand\"—it's imbued in Western cultural products and present in software and the internet which in turn service liberal ideals. What if it's no longer the case?",
"track": "Real World Ethereum",
"type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "payment",
- "p2p finance",
- "mobile"
- ],
- "tags": [
- "Protocol Design",
- "Scalability",
- "UI/UX",
- "Mobile",
- "Protocol Design",
- "Scalability",
- "UI/UX"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
"speakers": [
- "rene-reinsberg"
+ "afra-zhao-wang"
],
"eventId": "devcon-7",
- "slot_start": 1731574800000,
- "slot_end": 1731575400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1lk319WDhop2qBsR_BdMLAl1tdzOwri17ao4IPguI7Ac"
+ "slot_start": 1731650400000,
+ "slot_end": 1731651000000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1l0E0bgrVT-d4Vqx2zZeLBbCopXsf2glznve9weGlx2U"
},
"vector": [
0,
@@ -659299,10 +657894,10 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -659493,7 +658088,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -659516,7 +658110,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -659529,7 +658122,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -659610,7 +658202,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -660036,10 +658627,11 @@
2,
0,
0,
+ 2,
+ 0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -660053,45 +658645,48 @@
},
{
"session": {
- "id": "scaling-ethereum-with-das-an-iterative-approach",
- "sourceId": "JFWPRG",
- "title": "Scaling Ethereum with DAS: an iterative approach",
- "description": "In this time between the launch of 4844 and the possible launch of a first version of PeerDAS, we explore and explain the iterative approach that has been employed in the rollout of blobs and DAS to Ethereum, and discuss the past and future steps.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "id": "securing-ethereum",
+ "sourceId": "9FQPCQ",
+ "title": "Securing Ethereum",
+ "description": "Discussion from security leaders in the audit, crowd-sec and bug bounty space on the importance of Ethereum security, current trends and predictions for the space in the coming years.",
+ "track": "[CLS] ETH Escape - Speed Hacking Challenge",
+ "type": "Panel",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Blobspace",
- "Data Availability",
- "Ethereum Roadmap",
- "Scalability"
- ],
- "keywords": [
- "PeerDAS"
- ],
- "duration": 1522,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "567a45d310dc81275e061b69797f55ce5386ac2d95acdaf5d71076c274539d71",
- "sources_youtubeId": "toR2UKzE_zA",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731398400000,
- "slot_end": 1731400200000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1AIOGsICQD3wWyrBZ5kDP7FX-hHDQ53lT_n8M7Jdl_kI",
- "resources_slides": null,
"speakers": [
- "francesco"
- ]
+ "michael-lewellen",
+ "neville-grech",
+ "pietro-carta",
+ "michael-okeeffe",
+ "luna-tong"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731573000000,
+ "slot_end": 1731576300000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1m_-I_-ifsaORsMAY0_k78On1s9BICet-47EDiFzpEAM"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -660392,6 +658987,12 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -660653,6 +659254,49 @@
0,
0,
0,
+ 6,
+ 6,
+ 6,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -660677,7 +659321,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -660911,10 +659554,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -660984,69 +659625,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -661408,8 +659986,6 @@
2,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -661422,51 +659998,51 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "searcher-competition-in-block-building",
- "sourceId": "MHRYV9",
- "title": "Searcher Competition in Block Building",
- "description": "We study the amount of MEV captured by validators, as a function of searcher competition. The core is a suitable solution concept in this context that makes robust predictions independent of implementation details or specific mechanisms chosen. The surplus share of validators is a function of searcher competition. Searchers can obtain at most the marginal value increase of the winning block relative to the best block that can be built without them. We validate the theory empirically.",
- "track": "Cryptoeconomics",
+ "id": "securing-grandines-performance",
+ "sourceId": "GGWXYQ",
+ "title": "Securing Grandine's Performance",
+ "description": "Our project focuses on improving Grandine’s performance and stability through targeted benchmarking and profiling. By conducting a comparative analysis with Lighthouse, we aim to identify architectural optimizations, especially those related to parallelization. Establishing baseline metrics is key to this approach, as it allows us to focus on refining critical areas within Grandine for optimal, efficient performance, thereby supporting the robustness of the Ethereum network.",
+ "track": "[CLS] EPF Day",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Design",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Cooperative",
- "Game",
- "Theory;"
- ],
"tags": [
+ "Consensus",
+ "Consensus Mechanisms",
"Core Protocol",
- "Gaming",
- "Mechanism design",
- "MEV",
- "theory",
- "cooperative",
- "Core Protocol",
- "Mechanism design",
- "MEV"
+ "Cryptography",
+ "Security"
],
+ "keywords": [],
+ "duration": 813,
"language": "en",
- "speakers": [
- "akaki-mamageishvili"
- ],
+ "sources_swarmHash": "3c895500f7d570e1fc742742e5d135753d9fe1464ebae8ef9cf72bb0ac6582c2",
+ "sources_youtubeId": "GHLfYrBidco",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673459489dbb7a90e1204ed1.vtt",
+ "transcript_text": " All right, let's hear it for Zarathustra and Boma. Hi, guys. So we worked on consensus client performance profiling. Both of us had the same interest, starting off with Grandin We worked on consensus client performance profiling. Both of us had the same interests, starting off with Grandin and branching out a bit, as you do during work on a project. There's a couple of repos listed there. Two of them are on GitHub, because that's where everybody else is. And I myself prefer GitLab, so I threw that in. I'm going to hand it to Boma, who's going to take the first bit. Hello. Hello. Okay. Sorry. My name is Mercy, and I'm here to make a presentation. Although our project shifted a little bit, the initial goal was to work on security and testing. But due to some, I underestimated some things. And so I had to focus on performance analysis, the comparative analysis between the construction client. Okay. So, okay. Sorry, so the initial goal was to do a security and reliability of grinding, and then there was a shift in focus which transitioned to profiling multiple clients due to technical challenges which I faced. Oh, okay. Sorry. So first of all, I used so many performance tools. The ones that stood out to me was the flame graph and then implementing a timing matrix on grinding. This is an example of what a flame graph looks like. Although it's not quite readable because you have to click in and then out to really view. But, okay. So looking at these stacks, grinding is actually performing very well from the stack overview, although there is a drop down from the Tokyo runtime, which is at 61.79%, which had a minus 35% drop down. So the key observation here is there is a high trend utilization on 97% in system trends and initial setup, significant drop down to 62% in Tokyo runtime operations, and then a consistent performance across Tokyo tax management. Also, multi-trained worker execution showing similar patterns in different narratives. Okay, sorry. So this is the 35 percent. Looking at the system trade level, which is 97 percent, then the current level, which is 62 percent, and then the – which identifies it as 5% drop down. So the cliff there is kind of huge and the high performance areas are trade initialization, system level operations and then co-trend management which is pretty handled very well and performed very well in that aspect. So areas of investigation a disclaimer, this is a research project I will call it a research because so many things can change and then I might be wrong in some cases. So areas of investigation for me is the secure ties scheduling, which is at 62%, and then the synchro time overhead and the tax profiling efficiency. And talking about the timing metrics, which I had to implement, for now, okay, Silo suggested that I had to do a comparative analysis between grinding and then Lighthouse. For now, I only have the data on grinding, and I'm yet to produce the data for Lighthouse to properly do a comparative analysis, but this is basically how the data looks like, and I'm hoping to use this to do more investigation on formal—to do more analysis on formal verification and fuzzing, creating a targeted fuzzing and—what's it called? Formative analysis. Sorry. And— hold on. So the reason why I had to use tools like the frame graph and the timing matrix was to help me understand more about the conscientious client, because I really underestimated what it is to force and build a fuzzer for a conscientious client. Because coming from a smart contract security background, I thought it was the same perspective, but I was proven wrong, and the complexity was overwhelming. But using this analysis and using this data, I think I'll be able to produce and to come up with a strategy in order to build a fuzzer, which has to do with making it a targeted FOSA and also for formal verification. Because I understood that there is not much work on formal verification on Ethereum consensus clients. Thank you. I can hand it over to you. So small premise to the second part. So as I mentioned, we initially started working on Grandin. It was a slight shift in focus. Transitioned to doing this profiling of multiple clients. At least that's what I focused on. DevOps emphasis. I decided to go there since I have no experience doing any sort of DevOps work. And I figured having a couple of months seemed like a lot of time. Here, that's a good thing to pick up. So that was fun. Built my own server from secondhand part. First time doing that, running Proxmox. Pretty interesting experience. Learned a lot. Challenges, hardware constraints. I thought I had sufficient amount, but it turned out that maybe the minimum required specs listed are not entirely enough to run all the nodes on a single server. At least not the one that I decided to assemble. And regarding the outcome, there's limited data. The results are modest modest but valuable insight into running Ethereum nodes was acquired so let me tell you a bit about the setup that I used so I listed on the left side for you guys the consensus clients that are there and the versions of those that I used two of them don't have a version specified that's because I didn't manage to run them so they were not included I would like to of them don't have a version specified and that's because I didn't manage to run them so they were not included. I would like to include them at a later stage when I have the capacity to do so. In terms of hardware I have dedicated eight cores to each of these. RAM 32 gigabytes and the disk space is 2 terabytes and VME drive which is sufficient for all these clients to not be limited there. In the setup, I make sure that each of them running on a virtual machine is limited to this, basically. So there's no way that if one of the VMs isn't using all of its RAM that one of the others could use it because it's available. This is normally something that Proxmox supports, but that, of course, doesn't allow for a proper comparative analysis. Then the services that I also got to work with and got to learn about, and never mind, of course, I needed an execution client, and a whole bunch of other services that anybody who has done anything in DevOps probably knows. So Prometheus, obviously, for metrics. I'm not going to mention them all, but I will just say that these were a lot of tools that were new to me. Quite interesting to see how many services you actually need to run such a such a node in a useful way, so that you actually can monitor what's going on. Then I'm going to show a couple of figures on some of the data. It's a bit older data, but so be it. So this is the CPU usage that I measured over the course of about a week, a little longer, for four of the consensus clients that I mentioned. And now the question, obviously, is what does this mean? And I don't have a crystal clear answer to you. I do notice some things, which you'll probably also notice straight away, which is that Grandin seems, on the average, to have the lowest CPU usage. But there is somewhere a spike in the middle. I see that in a later figure. In the next figure, I'll show as well. And honestly, I'm curious what happened there, but I simply don't know. I probably need more data. From the metrics alone, it's not so clear. It could be various things. It might be something network related, could be something client specific. Simply don't have an answer for you there. Here I looked at the memory usage of the different clients. Also, you see the same spike in the same period, but it's for a different client. So yeah, there's definitely something going on there, and I would say that my suspicion is that it has something to do with my server at that point, since I see this weird pattern. But like I said, I have no straight answers for you. And then the last figure I will show, I think this is actually one of the things that is highly relevant. I only show Grandin and Lighthouse here, because the initial focus was more or less on Grandin, and for comparison also taking into consideration Lighthouse. So the number of pairs that you have is obviously very important and you can see that there are actually quite large spikes to the downside. I have the limit set at a hundred so that's why it looks kind of artificially kept there. But yeah if you lose a lot of pairs that that's obviously not a good sign. And well, it seems to be fairly, maybe not stable enough or not as stable as you might want it. So in terms of outlook, what I would like to do is refine and scale this node management. So I now have almost an automated setup for the provisioning of my VMs. I would still need to switch to NixOS or Telos to have it fairly immutable and item potent. Then I want to integrate ETH Docker. This is something that I simply didn't have enough time to properly look into. So so far what I've been using is Sedge. Well, I started with simple scripts and running local binaries and eventually went on to use Docker Compose. But yeah, I would like to move to Kubernetes and I would like to also explore ETH Docker because I think it offers some of the things that I was lacking or missing in Sedge. And then I only very recently, that is to say yesterday, learned about the secret shared validator. So I'm going to look into this. This is something in the direction that I was thinking I want to use this setup. I want to use this setup myself with an agentic system, because there I have a background. So I think it might actually partly at least overlap with the secret shared validator setup, because I was thinking in that same direction. And lastly, I want to optimize the data queries, because the idea of this agentic system would be to integrate those metrics so that the agent Can proactively take the necessary measures for example manager node if you see that your peers are getting too low maybe you need to well do something to To fix that Yeah, that is all I have for you. So then I only have a Thank you slide left. Obviously, Mario and Josh, it was amazing. Thanks so much for all the time and effort that you guys spent in granting us this opportunity to be part of the EPF. Yeah, I think that's it. Are there any questions? Thank you. Hey, thank you for an amazing talk. I was wondering if the notes that you ran were validators or just notes? No, also validators. Also validators. Yeah. Okay, so it might be nice to see the difference between, like, for each client, what's different if they're a validator and if they're not. Yeah, I agree. There's lots of experiments you could do. Really, really lots more. I would have liked the pieces and sort of working. And then you need to learn PromQL, okay? And then you learn a bit of PromQL and then you see all the metrics that are there. For example, Grafana, which I also used a little bit at somebody, I just decided, okay, I'm just going to do it. So, yeah, I agree. There's lots more. And those things would be interesting to look at, yeah. Amazing, thank you. Any other questions? Mario? Yeah, I was wondering, because you mentioned the setup with Proxmox and you want to automatize it, setup with Next. It's really cool. I'm just, you didn't really have in slides like some more specs about it. Like for example, what virtualization are you using with Proxmox? Like KVM or LXC or, yeah. KVM is what I'm using, but I could explore maybe alternatives. I haven't explored any alternatives there. So you think it's worth exploring? Just the Linux containers are good for servers as well. And I was wondering, like, because Proxmox supports both, and you just, yeah, you didn't have the details there, so I was wondering, like, which one. No, this would say. Yeah, cool. Thanks so much. Yeah. All right. Thank you, guys.",
"eventId": "devcon-7",
- "slot_start": 1731648600000,
- "slot_end": 1731649200000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1oRDP1vAH4P88oiBLEXOsJco7KgtJbQmYvKAeAkMug6Y"
+ "slot_start": 1731482100000,
+ "slot_end": 1731483000000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1prZ931qBVTXdBa8oGWfuFhX5yIKVdrAsZ9rAg99ejog",
+ "resources_slides": null,
+ "speakers": [
+ "mercy-boma-naps-nkari",
+ "zarathustra"
+ ]
},
"vector": [
- 0,
- 0,
- 6,
0,
0,
0,
@@ -661482,6 +660058,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -661907,7 +660484,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -662053,6 +660629,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -662214,6 +660792,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -662223,19 +660802,18 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -662327,7 +660905,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -662409,6 +660986,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -662665,7 +661243,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -662692,7 +661269,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -662781,6 +661357,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -662792,42 +661369,47 @@
0,
0,
0,
- 2,
0,
0
]
},
{
"session": {
- "id": "secondhand-liberalism-a-story-of-microdosing-internet-freedom",
- "sourceId": "TB8DG7",
- "title": "Secondhand Liberalism: A Story of Microdosing Internet Freedom",
- "description": "Liberalism isn't the default. For those growing up in non-Western societies, liberalism is often \"secondhand\"—it's imbued in Western cultural products and present in software and the internet which in turn service liberal ideals. What if it's no longer the case?",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
- "expertise": "",
- "audience": "Engineering",
+ "id": "security-frameworks-by-seal",
+ "sourceId": "A7TNUF",
+ "title": "Security Frameworks by SEAL",
+ "description": "Comprised of dedicated security specialists, SEAL aims to spread awareness and educate the community about Web3 security best practices and pitfalls. We address various challenges, compile accessible resources, and create new content. Open to all backgrounds, our guidelines provide comprehensive security frameworks for Web3 projects, offering best practices and practical solutions throughout their lifecycle. We aim to make Web3 a safer space for developers and users alike.",
+ "track": "Security",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Best practices",
+ "Guidelines",
+ "Frameworks."
+ ],
+ "tags": [
+ "Security",
+ "Hacks",
+ "Public good",
+ "framework",
+ "Hacks",
+ "Public good",
+ "Security"
+ ],
"language": "en",
"speakers": [
- "afra-zhao-wang"
+ "matta-the-red-guild"
],
"eventId": "devcon-7",
- "slot_start": 1731650400000,
- "slot_end": 1731651000000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1l0E0bgrVT-d4Vqx2zZeLBbCopXsf2glznve9weGlx2U"
+ "slot_start": 1731576600000,
+ "slot_end": 1731578400000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1HmUewjGmXzH3e1271bv_rXsd73TpbSS90ZBFslgi4ic"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -663101,6 +661683,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -663408,7 +661991,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -663577,6 +662159,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -663685,6 +662268,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -663739,6 +662323,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -663824,6 +662409,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -664139,11 +662725,10 @@
2,
0,
0,
- 2,
- 0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -664157,31 +662742,47 @@
},
{
"session": {
- "id": "securing-ethereum",
- "sourceId": "9FQPCQ",
- "title": "Securing Ethereum",
- "description": "Discussion from security leaders in the audit, crowd-sec and bug bounty space on the importance of Ethereum security, current trends and predictions for the space in the coming years.",
- "track": "[CLS] ETH Escape - Speed Hacking Challenge",
- "type": "Panel",
- "expertise": "",
- "audience": "Engineering",
+ "id": "security-of-fiat-shamir-transformation",
+ "sourceId": "VMNCS8",
+ "title": "Security of Fiat-Shamir transformation",
+ "description": "Fiat-Shamir transformation underlies virtually every SNARK used in the Ethereum ecosystem as it makes interactive proofs non-interactive. In this talk, we discuss the security issues if the transformation is used incorrectly (e.g., parallel repetition of a ZKP defined over a small field; such protocols became very popular thanks to their efficiency), provide examples, show the security loss that the transformation brings, and the concrete security of ZKP. Finally, we discuss best practices for k",
+ "track": "Applied Cryptography",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
- "language": "en",
- "speakers": [
- "michael-lewellen",
- "neville-grech",
- "pietro-carta",
- "michael-okeeffe",
- "luna-tong"
+ "tags": [
+ "Fiat-Shamir heuristic",
+ "STARK",
+ "Security",
+ "iop",
+ "Fiat-Shamir heuristic",
+ "Security",
+ "STARK"
+ ],
+ "keywords": [
+ "small fields",
+ "IOP"
],
+ "duration": 1593,
+ "language": "en",
+ "sources_swarmHash": "48a411b091a8c6046acad9b1ee6abd821654d0b9005b8e2e4fffe3fe33eac9c6",
+ "sources_youtubeId": "VIMnaOUvw08",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67345ac19dbb7a90e1395191.vtt",
+ "transcript_text": " I'd like to introduce our speaker today. His name is Michal. He's flown all the way from Poland, about a 17-hour trip. So why don't you give a round of applause to Michal. How many pieces do you have? There's five. Does it work? Okay, perfect. Hello, thanks for inviting me to talk today. So my talk is about the security of Fiat Shamir transformation. So basically, the security of the transformation that allows you to use all these snarks, starks, on-chain as non-interactive proof instead of having them as a communication between prover and verifier. Okay, so before we dive in, let's talk very briefly about zero-knowledge proofs. So in zero-knowledge proofs, we usually have these two parties, prover and verifier. The prover wants to convince the verifier about veracity of some particular statement. Formally, we want to say that particular statement belongs to some predefined language, but we don't need to go into such details now. So prover has two inputs. One is the statement that it wants to prove, and another is witness. So for example, when you have... The statement could be like a circuit C executed on some input A evaluates to B, and witness could be like all the values from this circuit from very bottom to the top, and, right, it should end with B. So in zero knowledge proofs we don't give the verifier that the full knowledge of the circuit we only give the statement the statement of the prover. This also comes from the fact that usually we can write statements in a much shorter way than witnesses. So from zero-knowledge proofs, we require basically three properties. The first one is completeness. So we want to say that if both prover and verifier are honest, then prover will be able to convince the verifier about the veracity of the statement. Another which I claim is like probably the most important one is soundness. So here we want to say that if the prover is malicious and the statement is incorrect, then the probability that the verifier will accept such statement is negligible. The different flavor of soundness is knowledge soundness, and this is what we usually use. And this is like a stronger notion of soundness. So here, if verifier accepts the proof, then we know that the prover knows the witness. And finally we have zero knowledge that we really don't use in blockchain applications, at least for now. So here we say that protocol is zero knowledge if the verifier learns nothing about the witness from this communication with the prover. Okay, so let's talk about how snarks are built. So sorry for this very theoretical slide. There will be few of them here. So, Starks and Snarks start as interactive proof between this prover and verifier. So we design our Snarks as protocols where the prover sends some polynomials to some imaginary particle called oracles. These polynomials, for example, represent very big computations. So these polynomials are huge. When these polynomials are sent, the verifier also replies with some challenges that also provide some information to the prover how these polynomials should be built. Eventually, the verifier asks this oracle that got all these polynomials to evaluate these polynomials for them. So it picks some evaluation point and gets the evaluations. So finally, the proof is like the set of all these polynomials sent by the prover, along with all challenges that the verifier sent, evaluation point, and evaluation of the polynomials at the evaluation point. So there are a few problems with this approach. O is like this imaginary party that really doesn't exist in real life. And since these polynomials represent all this computation, they are huge. So we don't want that. So we need to make a next step. So for next step, we use something called polynomial commitments, which basically allow the prover to send like a short digest that represents the polynomial instead the whole polynomial. And importantly, the verifier can also evaluate this polynomial by sending like the evaluation points to the prover such that this evaluation can be verified. So now we can replace our oracle just by using the polynomial commitments and that also makes our proof much shorter, right, Because instead of full polynomials, we send this very short digest. So now the communication looks like we have a prover that sends some.",
"eventId": "devcon-7",
- "slot_start": 1731573000000,
- "slot_end": 1731576300000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1m_-I_-ifsaORsMAY0_k78On1s9BICet-47EDiFzpEAM"
+ "slot_start": 1731482400000,
+ "slot_end": 1731484200000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1qlPnS97cEpEKuQEuS06efm97LnehdTDo-7FRoyWVIHY",
+ "resources_slides": null,
+ "speakers": [
+ "michal-zajac"
+ ]
},
"vector": [
0,
@@ -664194,6 +662795,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -664203,7 +662806,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -664500,7 +663102,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -664771,14 +663372,8 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
- 0,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -664939,6 +663534,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -665149,6 +663745,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -665411,6 +664008,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -665496,9 +664095,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
2,
@@ -665513,51 +664112,57 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "securing-grandines-performance",
- "sourceId": "GGWXYQ",
- "title": "Securing Grandine's Performance",
- "description": "Our project focuses on improving Grandine’s performance and stability through targeted benchmarking and profiling. By conducting a comparative analysis with Lighthouse, we aim to identify architectural optimizations, especially those related to parallelization. Establishing baseline metrics is key to this approach, as it allows us to focus on refining critical areas within Grandine for optimal, efficient performance, thereby supporting the robustness of the Ethereum network.",
- "track": "[CLS] EPF Day",
+ "id": "security-through-obscurity-using-microdots-to-store-secrets",
+ "sourceId": "UHQDPU",
+ "title": "Security through obscurity. Using microdots to store secrets.",
+ "description": "Key custody remains a tricky problem to solve. Most of the focus around improving the security of key custody revolve around software based approaches like secret sharing. However, physical approaches are also possible. \r\n\r\nThis talk discusses on how to secure secrets using microdots and how microdots may be fabricated at home with legally accessible tools.\r\n\r\nMicrodots is a technique which allows one to shrink documents down. This allows one to embed secrets in documents in plain sight.",
+ "track": "Security",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Lobby",
"featured": false,
"doNotRecord": false,
"tags": [
- "Consensus",
- "Consensus Mechanisms",
- "Core Protocol",
+ "Digital Sovereignty",
"Cryptography",
+ "Security",
+ "Hardware wallets",
+ "Custody",
+ "Cryptography",
+ "Custody",
+ "Digital Sovereignty",
+ "Hardware wallets",
"Security"
],
- "keywords": [],
- "duration": 813,
+ "keywords": [
+ "None"
+ ],
+ "duration": 579,
"language": "en",
- "sources_swarmHash": "3c895500f7d570e1fc742742e5d135753d9fe1464ebae8ef9cf72bb0ac6582c2",
- "sources_youtubeId": "GHLfYrBidco",
+ "sources_swarmHash": "70b7a1a2acf3ec307ad982db5ea9e354b109ab2b5981ba87ee71c5967e486a52",
+ "sources_youtubeId": "3mXa1oeHzzA",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673459489dbb7a90e1204ed1.vtt",
- "transcript_text": " All right, let's hear it for Zarathustra and Boma. Hi, guys. So we worked on consensus client performance profiling. Both of us had the same interest, starting off with Grandin We worked on consensus client performance profiling. Both of us had the same interests, starting off with Grandin and branching out a bit, as you do during work on a project. There's a couple of repos listed there. Two of them are on GitHub, because that's where everybody else is. And I myself prefer GitLab, so I threw that in. I'm going to hand it to Boma, who's going to take the first bit. Hello. Hello. Okay. Sorry. My name is Mercy, and I'm here to make a presentation. Although our project shifted a little bit, the initial goal was to work on security and testing. But due to some, I underestimated some things. And so I had to focus on performance analysis, the comparative analysis between the construction client. Okay. So, okay. Sorry, so the initial goal was to do a security and reliability of grinding, and then there was a shift in focus which transitioned to profiling multiple clients due to technical challenges which I faced. Oh, okay. Sorry. So first of all, I used so many performance tools. The ones that stood out to me was the flame graph and then implementing a timing matrix on grinding. This is an example of what a flame graph looks like. Although it's not quite readable because you have to click in and then out to really view. But, okay. So looking at these stacks, grinding is actually performing very well from the stack overview, although there is a drop down from the Tokyo runtime, which is at 61.79%, which had a minus 35% drop down. So the key observation here is there is a high trend utilization on 97% in system trends and initial setup, significant drop down to 62% in Tokyo runtime operations, and then a consistent performance across Tokyo tax management. Also, multi-trained worker execution showing similar patterns in different narratives. Okay, sorry. So this is the 35 percent. Looking at the system trade level, which is 97 percent, then the current level, which is 62 percent, and then the – which identifies it as 5% drop down. So the cliff there is kind of huge and the high performance areas are trade initialization, system level operations and then co-trend management which is pretty handled very well and performed very well in that aspect. So areas of investigation a disclaimer, this is a research project I will call it a research because so many things can change and then I might be wrong in some cases. So areas of investigation for me is the secure ties scheduling, which is at 62%, and then the synchro time overhead and the tax profiling efficiency. And talking about the timing metrics, which I had to implement, for now, okay, Silo suggested that I had to do a comparative analysis between grinding and then Lighthouse. For now, I only have the data on grinding, and I'm yet to produce the data for Lighthouse to properly do a comparative analysis, but this is basically how the data looks like, and I'm hoping to use this to do more investigation on formal—to do more analysis on formal verification and fuzzing, creating a targeted fuzzing and—what's it called? Formative analysis. Sorry. And— hold on. So the reason why I had to use tools like the frame graph and the timing matrix was to help me understand more about the conscientious client, because I really underestimated what it is to force and build a fuzzer for a conscientious client. Because coming from a smart contract security background, I thought it was the same perspective, but I was proven wrong, and the complexity was overwhelming. But using this analysis and using this data, I think I'll be able to produce and to come up with a strategy in order to build a fuzzer, which has to do with making it a targeted FOSA and also for formal verification. Because I understood that there is not much work on formal verification on Ethereum consensus clients. Thank you. I can hand it over to you. So small premise to the second part. So as I mentioned, we initially started working on Grandin. It was a slight shift in focus. Transitioned to doing this profiling of multiple clients. At least that's what I focused on. DevOps emphasis. I decided to go there since I have no experience doing any sort of DevOps work. And I figured having a couple of months seemed like a lot of time. Here, that's a good thing to pick up. So that was fun. Built my own server from secondhand part. First time doing that, running Proxmox. Pretty interesting experience. Learned a lot. Challenges, hardware constraints. I thought I had sufficient amount, but it turned out that maybe the minimum required specs listed are not entirely enough to run all the nodes on a single server. At least not the one that I decided to assemble. And regarding the outcome, there's limited data. The results are modest modest but valuable insight into running Ethereum nodes was acquired so let me tell you a bit about the setup that I used so I listed on the left side for you guys the consensus clients that are there and the versions of those that I used two of them don't have a version specified that's because I didn't manage to run them so they were not included I would like to of them don't have a version specified and that's because I didn't manage to run them so they were not included. I would like to include them at a later stage when I have the capacity to do so. In terms of hardware I have dedicated eight cores to each of these. RAM 32 gigabytes and the disk space is 2 terabytes and VME drive which is sufficient for all these clients to not be limited there. In the setup, I make sure that each of them running on a virtual machine is limited to this, basically. So there's no way that if one of the VMs isn't using all of its RAM that one of the others could use it because it's available. This is normally something that Proxmox supports, but that, of course, doesn't allow for a proper comparative analysis. Then the services that I also got to work with and got to learn about, and never mind, of course, I needed an execution client, and a whole bunch of other services that anybody who has done anything in DevOps probably knows. So Prometheus, obviously, for metrics. I'm not going to mention them all, but I will just say that these were a lot of tools that were new to me. Quite interesting to see how many services you actually need to run such a such a node in a useful way, so that you actually can monitor what's going on. Then I'm going to show a couple of figures on some of the data. It's a bit older data, but so be it. So this is the CPU usage that I measured over the course of about a week, a little longer, for four of the consensus clients that I mentioned. And now the question, obviously, is what does this mean? And I don't have a crystal clear answer to you. I do notice some things, which you'll probably also notice straight away, which is that Grandin seems, on the average, to have the lowest CPU usage. But there is somewhere a spike in the middle. I see that in a later figure. In the next figure, I'll show as well. And honestly, I'm curious what happened there, but I simply don't know. I probably need more data. From the metrics alone, it's not so clear. It could be various things. It might be something network related, could be something client specific. Simply don't have an answer for you there. Here I looked at the memory usage of the different clients. Also, you see the same spike in the same period, but it's for a different client. So yeah, there's definitely something going on there, and I would say that my suspicion is that it has something to do with my server at that point, since I see this weird pattern. But like I said, I have no straight answers for you. And then the last figure I will show, I think this is actually one of the things that is highly relevant. I only show Grandin and Lighthouse here, because the initial focus was more or less on Grandin, and for comparison also taking into consideration Lighthouse. So the number of pairs that you have is obviously very important and you can see that there are actually quite large spikes to the downside. I have the limit set at a hundred so that's why it looks kind of artificially kept there. But yeah if you lose a lot of pairs that that's obviously not a good sign. And well, it seems to be fairly, maybe not stable enough or not as stable as you might want it. So in terms of outlook, what I would like to do is refine and scale this node management. So I now have almost an automated setup for the provisioning of my VMs. I would still need to switch to NixOS or Telos to have it fairly immutable and item potent. Then I want to integrate ETH Docker. This is something that I simply didn't have enough time to properly look into. So so far what I've been using is Sedge. Well, I started with simple scripts and running local binaries and eventually went on to use Docker Compose. But yeah, I would like to move to Kubernetes and I would like to also explore ETH Docker because I think it offers some of the things that I was lacking or missing in Sedge. And then I only very recently, that is to say yesterday, learned about the secret shared validator. So I'm going to look into this. This is something in the direction that I was thinking I want to use this setup. I want to use this setup myself with an agentic system, because there I have a background. So I think it might actually partly at least overlap with the secret shared validator setup, because I was thinking in that same direction. And lastly, I want to optimize the data queries, because the idea of this agentic system would be to integrate those metrics so that the agent Can proactively take the necessary measures for example manager node if you see that your peers are getting too low maybe you need to well do something to To fix that Yeah, that is all I have for you. So then I only have a Thank you slide left. Obviously, Mario and Josh, it was amazing. Thanks so much for all the time and effort that you guys spent in granting us this opportunity to be part of the EPF. Yeah, I think that's it. Are there any questions? Thank you. Hey, thank you for an amazing talk. I was wondering if the notes that you ran were validators or just notes? No, also validators. Also validators. Yeah. Okay, so it might be nice to see the difference between, like, for each client, what's different if they're a validator and if they're not. Yeah, I agree. There's lots of experiments you could do. Really, really lots more. I would have liked the pieces and sort of working. And then you need to learn PromQL, okay? And then you learn a bit of PromQL and then you see all the metrics that are there. For example, Grafana, which I also used a little bit at somebody, I just decided, okay, I'm just going to do it. So, yeah, I agree. There's lots more. And those things would be interesting to look at, yeah. Amazing, thank you. Any other questions? Mario? Yeah, I was wondering, because you mentioned the setup with Proxmox and you want to automatize it, setup with Next. It's really cool. I'm just, you didn't really have in slides like some more specs about it. Like for example, what virtualization are you using with Proxmox? Like KVM or LXC or, yeah. KVM is what I'm using, but I could explore maybe alternatives. I haven't explored any alternatives there. So you think it's worth exploring? Just the Linux containers are good for servers as well. And I was wondering, like, because Proxmox supports both, and you just, yeah, you didn't have the details there, so I was wondering, like, which one. No, this would say. Yeah, cool. Thanks so much. Yeah. All right. Thank you, guys.",
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731482100000,
- "slot_end": 1731483000000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1prZ931qBVTXdBa8oGWfuFhX5yIKVdrAsZ9rAg99ejog",
+ "slot_start": 1731406200000,
+ "slot_end": 1731406800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1zGqyVZiy__TgQYZes9fefN5S6uBUQLT9Yl6wbxjJ-2M",
"resources_slides": null,
"speakers": [
- "mercy-boma-naps-nkari",
- "zarathustra"
+ "jseam"
]
},
"vector": [
+ 6,
0,
0,
0,
@@ -665573,9 +664178,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -666150,7 +664752,6 @@
0,
0,
6,
- 6,
0,
0,
0,
@@ -666315,7 +664916,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -666323,13 +664923,12 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -666362,6 +664961,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -666504,7 +665104,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -666648,6 +665247,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -666787,6 +665387,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -666875,7 +665476,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -666888,50 +665488,57 @@
0,
0,
0,
- 0
+ 0,
+ 2
]
},
{
"session": {
- "id": "security-frameworks-by-seal",
- "sourceId": "A7TNUF",
- "title": "Security Frameworks by SEAL",
- "description": "Comprised of dedicated security specialists, SEAL aims to spread awareness and educate the community about Web3 security best practices and pitfalls. We address various challenges, compile accessible resources, and create new content. Open to all backgrounds, our guidelines provide comprehensive security frameworks for Web3 projects, offering best practices and practical solutions throughout their lifecycle. We aim to make Web3 a safer space for developers and users alike.",
- "track": "Security",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "id": "semaphore-v4",
+ "sourceId": "ZU9D8U",
+ "title": "Semaphore V4",
+ "description": "Semaphore is a protocol enabling individuals to prove group membership and send messages (such as votes or endorsements) anonymously. The latest version enhances efficiency and simplifies the use of libraries and contracts. This presentation will cover the new features, project vision, and the importance and challanges of zero-knowledge technologies.",
+ "track": "Applied Cryptography",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Best practices",
- "Guidelines",
- "Frameworks."
- ],
"tags": [
- "Security",
- "Hacks",
- "Public good",
- "framework",
- "Hacks",
- "Public good",
- "Security"
+ "Privacy",
+ "Zero-Knowledge",
+ "User Experience",
+ "proof-of",
+ "membership",
+ "Privacy",
+ "User Experience",
+ "Zero-Knowledge"
],
- "language": "en",
- "speakers": [
- "matta-the-red-guild"
+ "keywords": [
+ "semaphore",
+ "anonymity sets",
+ "proof of membership"
],
+ "duration": 1035,
+ "language": "en",
+ "sources_swarmHash": "619dc838e91326f82a78ebd1207f07fa45e9941e162c7999de38f6d08fee6691",
+ "sources_youtubeId": "OErC2MyIKjY",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330d403a168eb535f16a2c.vtt",
+ "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the Ethereum Foundation. And today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Addestation service, SKIMail, TLS Notary, and POP. So some projects can be useful for privacy preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-civil, too. So the three main ideas from this presentation that I would like you to remember are privacy privacy groups can be used to verify credentials to have a better user experience in your applications. Also that you can combine different anti-civil mechanisms to have a stronger one. That's very important. Maybe it's not your case, case for your application, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. Like, this works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes. Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this commitment to a Bandada group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with the members in your group any other questions it's over there I see some people wearing the mere cat hat unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, there might be a reason to remove someone forcefully. Are there any practical way to do that? Yeah, yeah. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is an easy way if you are using code or not. Yeah. Can you explain the mechanic behind, like how can you maintain privacy of everyone and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean, the person, it's a commitment. So people don't know, like, who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and Okay. Thank you, Vivian. Thank you. Our next talk is also going to be about Semaphore v4. So let's welcome our next speaker, Sidur. He's going to show us some new features of Semaphore v4 and some of the importance of the ZK technology. Let's welcome him. Hi. So, hi, folks. I will start introducing myself, and then I'll present some news regarding Semaphore and our future plans. So, I'm Cedar. I work as a software engineer with the PSE team, and in the past years, I have mainly focused on improving the developer experience of some PSE projects. I'm talking about what Semaphore is. Semaphore v4, so some news. And then our roadmap. So, first of all, Semaphore, as far as I know, is one of the simplest client-side zero-log protocols. So the core circuits only contains 22 lines of code without documentation and, like, empty lines. Generating a proof only takes less than one second on browsers, and verifying a proof on-chain only consumes less than 300,000 units of gas, which means, like, around five cents on Arbitrum. But what is it? So Semaphore is a zero-knowledge protocol that allows users to prove their membership in a group and send messages such as votes or feedback without revealing their identity. In addition, it also provides an alifier mechanism to present users from reusing existing proofs. So Semaphore is basically a general-purpose protocol, so you can use it for any use case where you need a layer of privacy. We have been working on Semaphore for a few years now, and we have mainly focused on developer experience until v3 but with the latest version before we also focused on interoperability and efficiency and on-chain costs in particular we have made two important change we have a new identity schema which uses EDDSA keeper and we have optimized the data structure for groups. So let's go a little bit deeper. We replaced the old identity schema with an E-D-D-S-A keeper. E-D-D-S-A is one of the most efficient public key cryptography algorithms using zero-knowledge circuits, and it makes the new version of Sphemafor much more compatible with other existing protocols which use eDSA. In the old schema, the public commitment, which is like the public identifier of the Semaphore identity, was a Poseidon hash of a secret. In the new schema, the public commitment is the Poseidon hash of the eDSA public key. And in addition, it also allows users to sign messages and verify signatures inside and outside ZKey proofs or circuits, which has been and will be hopefully pretty useful for some applications like Zupass, which uses Semaphore v4. So then we optimized the old data structure, the incremental Merkle tree, and we created a new data structure, which is based on the old one,, the incremental Merkle tree. And we created a new data structure, which is based on the old one, the lean incremental Merkle tree. So just small improvements that made it much more efficient, especially when the tree doesn't have many leaves, so for small groups. The key improvements are two. Zero hashes are no longer required. And the tree grows dynamically now. So zero hashes. I just want to show the difference between these two trees. In the old implementation, if the parent node has one child, it will be calculated as the hash of that child node and the zero hash. In the new implementation on the right, the parent node can actually equal the child node itself, so no need to calculate any hash in those cases. The second important change is about the dynamic depth. In the old implementation the tree has a static depth. Each insertion needs to update a number of nodes which equals the static depth of the tree, and in the new implementation, the tree depth grows with the number of leaves, which means each insertion would only require updating a number of nodes proportional to the current number of leaves. So this is quite complex. So please, if you want to know more about this data structure, go to the paper we published a few months ago in the ZKeyKit repository below. Finally, what we would like to do in the next months, we would like to have a new Explorer, which people can use to see on-chain groups, and which admins can use to create and manage groups. We would like to work on a new version of RLN which is pretty similar to Semaphore. They share the same code but RLN works with an additional layer to prevent spam. We would like to add additional tutorials to the documentation and possibly have like specifications for Semaphore v4, something that people ask us a lot of times. We will also explore and consider improving systems, of course, and try to keep ourselves updated on the latest technologies to improve the key requirements of the protocol. So some links you can use to connect and ask us any questions. Yeah, thank you very much Thank You Sidor any questions oh there's one there do you want to give it a go it's on your side hello test thank you for your speech it was good I'm just curious to know more about Semaphore's business model. The tech sounds amazing, but I'm curious, is there a way to generate a profit from this? No. I mean, we are funded by the Thiem Foundation, and we are not thinking about any way to make profit. Okay, thank you. I think we're also not allowed to speak about profits, just from what I heard. Okay, thank you. Hi, I was wondering, to upgrade or migrate from previous version, does that mean like existing project need to generate new identities? 제작진이 새로운 정보를 생성해야 하는 거죠? 네, 새로운 정보를 생성해야 합니다. 그리고 새로운 정보를 생성하는 방법은 세마폴 B4의 정보를 생성하는 것입니다. 그래서, 이전의 정보를 생성하고, 전기 문제를 생성하는 것입니다. and then deriving the private key from the previous secret. I have a question for how the protocol works. Do all the nodes need to be online at the same time? Where are you, sorry. Hi. Sorry. Hi. Hi. Do all the nodes who want to take part in this protocol need to be online at the same time, or is it possible to establish the group without all the participants seeing the other participant at any point in time can you repeat your question sorry about it's about the liveness of the participants yeah so can we establish a semaphore based communication for example even if some of the nodes are only online for a certain short period of time or do they all have to be online at the same time to calculate these secrets yes they have to be online yes on chain at the same time okay thank you Thank you. Any other questions? We have one at the front row here. Hi. Hi, what are the advantages of using the lean IMT now data structure for like the aerodynamic depth of the tree? I think one advantage is that with the old static with the old incremental Merkel tree with static depth we had a range of three of supported three depths from 16 to 32. And even if the group is small, like with 10 members, you had to use a Merkle tree with a static depth which was like 16. So bigger... So it's a storage then? Yes, for storage. And the generation of the proof as well needs more time because the circuits have more constraints. Okay, I see. Thank you. Okay, we still have some time for questions if you have any.",
"eventId": "devcon-7",
- "slot_start": 1731576600000,
- "slot_end": 1731578400000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1HmUewjGmXzH3e1271bv_rXsd73TpbSS90ZBFslgi4ic"
+ "slot_start": 1731397200000,
+ "slot_end": 1731397800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/12uKp51aS4tQMokLfQJRDQlh518PRLNinkH3148Cq9Do",
+ "resources_slides": null,
+ "speakers": [
+ "cedoor"
+ ]
},
"vector": [
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -666942,6 +665549,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -667202,7 +665810,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -667522,6 +666129,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -667680,7 +666288,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -667693,9 +666300,11 @@
0,
0,
0,
+ 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -667789,13 +666398,13 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -667844,7 +666453,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -667931,7 +666539,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -668050,6 +666657,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -668157,6 +666765,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -668240,6 +666849,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -668249,8 +666859,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -668263,46 +666871,39 @@
},
{
"session": {
- "id": "security-of-fiat-shamir-transformation",
- "sourceId": "VMNCS8",
- "title": "Security of Fiat-Shamir transformation",
- "description": "Fiat-Shamir transformation underlies virtually every SNARK used in the Ethereum ecosystem as it makes interactive proofs non-interactive. In this talk, we discuss the security issues if the transformation is used incorrectly (e.g., parallel repetition of a ZKP defined over a small field; such protocols became very popular thanks to their efficiency), provide examples, show the security loss that the transformation brings, and the concrete security of ZKP. Finally, we discuss best practices for k",
- "track": "Applied Cryptography",
- "type": "Talk",
+ "id": "shadow-network-simulations",
+ "sourceId": "H7HCJJ",
+ "title": "Shadow Network Simulations",
+ "description": "In my EPF project, I implemented Ethshadow, a configuration generator for simulating Ethereum networks using Shadow, and used it to research improvements to the current state of PeerDAS and to estimate the effects of IDONTWANT on node bandwidth. In this presentation, I will present my findings and make a case for testing using Ethshadow.",
+ "track": "[CLS] EPF Day",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Research",
"featured": false,
"doNotRecord": false,
"tags": [
- "Fiat-Shamir heuristic",
- "STARK",
- "Security",
- "iop",
- "Fiat-Shamir heuristic",
- "Security",
- "STARK"
- ],
- "keywords": [
- "small fields",
- "IOP"
+ "Core Protocol",
+ "Layer 1",
+ "Testing"
],
- "duration": 1593,
+ "keywords": [],
+ "duration": 936,
"language": "en",
- "sources_swarmHash": "48a411b091a8c6046acad9b1ee6abd821654d0b9005b8e2e4fffe3fe33eac9c6",
- "sources_youtubeId": "VIMnaOUvw08",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "1jUvR9kBmpg",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67345ac19dbb7a90e1395191.vtt",
- "transcript_text": " I'd like to introduce our speaker today. His name is Michal. He's flown all the way from Poland, about a 17-hour trip. So why don't you give a round of applause to Michal. How many pieces do you have? There's five. Does it work? Okay, perfect. Hello, thanks for inviting me to talk today. So my talk is about the security of Fiat Shamir transformation. So basically, the security of the transformation that allows you to use all these snarks, starks, on-chain as non-interactive proof instead of having them as a communication between prover and verifier. Okay, so before we dive in, let's talk very briefly about zero-knowledge proofs. So in zero-knowledge proofs, we usually have these two parties, prover and verifier. The prover wants to convince the verifier about veracity of some particular statement. Formally, we want to say that particular statement belongs to some predefined language, but we don't need to go into such details now. So prover has two inputs. One is the statement that it wants to prove, and another is witness. So for example, when you have... The statement could be like a circuit C executed on some input A evaluates to B, and witness could be like all the values from this circuit from very bottom to the top, and, right, it should end with B. So in zero knowledge proofs we don't give the verifier that the full knowledge of the circuit we only give the statement the statement of the prover. This also comes from the fact that usually we can write statements in a much shorter way than witnesses. So from zero-knowledge proofs, we require basically three properties. The first one is completeness. So we want to say that if both prover and verifier are honest, then prover will be able to convince the verifier about the veracity of the statement. Another which I claim is like probably the most important one is soundness. So here we want to say that if the prover is malicious and the statement is incorrect, then the probability that the verifier will accept such statement is negligible. The different flavor of soundness is knowledge soundness, and this is what we usually use. And this is like a stronger notion of soundness. So here, if verifier accepts the proof, then we know that the prover knows the witness. And finally we have zero knowledge that we really don't use in blockchain applications, at least for now. So here we say that protocol is zero knowledge if the verifier learns nothing about the witness from this communication with the prover. Okay, so let's talk about how snarks are built. So sorry for this very theoretical slide. There will be few of them here. So, Starks and Snarks start as interactive proof between this prover and verifier. So we design our Snarks as protocols where the prover sends some polynomials to some imaginary particle called oracles. These polynomials, for example, represent very big computations. So these polynomials are huge. When these polynomials are sent, the verifier also replies with some challenges that also provide some information to the prover how these polynomials should be built. Eventually, the verifier asks this oracle that got all these polynomials to evaluate these polynomials for them. So it picks some evaluation point and gets the evaluations. So finally, the proof is like the set of all these polynomials sent by the prover, along with all challenges that the verifier sent, evaluation point, and evaluation of the polynomials at the evaluation point. So there are a few problems with this approach. O is like this imaginary party that really doesn't exist in real life. And since these polynomials represent all this computation, they are huge. So we don't want that. So we need to make a next step. So for next step, we use something called polynomial commitments, which basically allow the prover to send like a short digest that represents the polynomial instead the whole polynomial. And importantly, the verifier can also evaluate this polynomial by sending like the evaluation points to the prover such that this evaluation can be verified. So now we can replace our oracle just by using the polynomial commitments and that also makes our proof much shorter, right, Because instead of full polynomials, we send this very short digest. So now the communication looks like we have a prover that sends some.",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67347cd49dbb7a90e16882fa.vtt",
+ "transcript_text": " Hi everyone, thank you. My name is Daniel Knopik and I worked on shadow network simulations. The usual clicker problems. Thanks. Yeah. So, in my opinion, network simulations are awesome because they allow testing changes without rolling out to public deaf nets or even test nets which is lower takes synchronization and time and Small local deafness are possible but with a software called shadow We can actually run huge simulations with thousands of nodes. And also with actual clients, like not any code written dedicated to the simulations. So I kind of had a three-phase project. First, I wanted to prepare a tool that allowed me to easily set up these shadow simulations with theorem clients. That is easier said than done because shadow can be kind of finicky sometimes. set up these shadow simulations with theorem clients. That is easier said than done because shadow can be kind of finicky sometimes, so it took a while. Yeah, in the second phase, I want to run experiments specifically on PeerDust and IDon'tWant, also known as GossipSub1.2. And in the third phase, I thought maybe if I saw in the experiments that this is actually a useful tool, I wanted to polish it and actually did, and thus, EthShadow was born. So to sum it up, there are like two main artifacts from my project, the experiment results and ETH Shadow itself. In this presentation, I will kind of focus on my results from PeerDust, and afterwards, also show you slowly or quickly ETH Shadow. Right. So, PeerDust. I won't have time to explain it as fully. So I'm just going to assume there's some awareness of what that is. Um, few points. It's an update to scale blobs and the basic principle is that we want to split the blobs into parts, which we call columns with every note taking custody of some of those columns. And there are some network changes required for this to make sure that the nodes properly distribute the columns across the network, and also so-called super nodes can reconstruct the blobs if they have enough columns. And right now there's like 128 additional subnets in gossip sub which all need to be covered by when a node wants to be proposed, right? We need to get every column out so yeah. Okay so I decided to run some simulations to help the research and development effort. Keep in mind that all results that I present here are like a few months old at this point, so the situation might be better at this point. So my simulation setup involved 1,000 nodes with Reth, Lighthouse, and Lighthouse validator client on each, with 4,000 validators, and in each experiment I simulated 45 minutes of simulated time. For a large simulation like this we want to run on some server that is sufficiently large that the simulation is fast enough for us. And I kind of experimented around a lot to make sure to get like, get nice performance going and kind of settled on a certain instance type you can see it there if you want to run your own simulations with the size and my simulations took a round of four hours per like 45 minutes of simulated time and so the cost of simulation came around at $10. Right. But if you want, like, also run smaller simulations, you can also do this on your laptop. Like, you don't need such a beefy server. This is just, like, my setup for the peer-to-peer simulations. So first I just tried running it on the current implementation in Lighthouse, and the simulated networks quickly fell apart because they lost sync and cannot really sync back up again. And that was kind of similar what was seen on DevNet at the time across basically all clients. So, I thought about how do I measure performance, and I had several metrics, but right here on DevNet at the time across basically all clients. So I thought about how do I measure performance and I had several metrics but right here I will focus on what I call score which is how many slots can over 66% of the network stay in sync. And with the unmodified client with the default configuration, zero. Like immediately after we posted blobs to the network, we lost sync. But I also noticed that if I designate every node as a super node, so custodying all the columns, not just eight or four, then the network stayed stable until the end. So I had the suspicion that something is wrong with the distribution of columns when we just don't broadcast all the columns at all times to everyone. And also that might be something with supernode reconstruction of the blobs might be wrong. Yeah. So, and yeah, the investigation showed that the problem is that if a node could not send all the data out, it would not retry that at all, causing some columns to get lost and custodying nodes for those columns would just not deem the data is available and would just accept the block and the sync and they could not catch up I guess the super nodes were not enough for that. So how do we fix this? I did some simulations where I varied the specs and I did a lot of different variations. I will focus on three here. We could increase the number of peers because if you have more peers, the likelihood that we actually cover all the columns when proposing a block with our peers is higher. So yeah, the base spec or the base configuration in lighthouse looks for 100 peers 150 peers scored 10 with the metric I just mentioned 200 Already 56 and 300 survived the whole simulation so we could see that confirming our theory this improves the situation Next up I increase the number of columns covered per each peer, which should have the same effect, right, because the total number of covered columns also increases with changing this. Increasing from 4 to 8, score 10, and 16 already survived the whole simulation. Finally, there should be an emoji here. The, you know, the diagonal face. All right. Increasing the number of supernodes, which should reconstruct the full blobs, like all columns, if they have half or more. Increasing to 10, scored 0 to 25 of 1,000, right? Scored 2, and 75 also 2. increasing to 10 scored 0 to 25 of thousand right let's go to and 75 also 2 and at that point I didn't test any further because I Want to kind of keep it in? Somewhat realistic scape and I'm not sure how many super notes there will be but we shouldn't in my opinion set the assumption too high all right but we shouldn't, in my opinion, set the assumption too high. All right. If you want to know more about that, there are my weekly reports where I go into a bit more detail. So let's move on to the state of each shadow, like the tool I developed. Because seeing these simulations, I thought, hey, this is kind of useful. I have an iterative approach and can evaluate different configurations. So I spent some weeks in the end to make it available for everyone. And the source is available on GitHub at Ethereum slash ethshadow. Right now there's like first class support for Geth and Lighthouse and there's some experimental support for Reth and Teku. There is some documentation that for Reth and Tiku. There is some documentation that has to be written. For basic use cases, there's good documentation already, so you can check it out. And I think in some cases, usability can be improved. The hard part is that Shadow needs a lot of work for all clients to work in shadow. The reason for that is the technical. Basically we need support from our Linux system calls in shadow. Um, and this is a lot of effort. Unfortunately I, um, kind of won't have much time. So I hope that in the coming Weeks a month I can at least help on the side of it to maintain this But I hope to also get the attention from from the core deaths to help me or help us all Hopefully soon have its shadow for all the clients Okay, there are some things to be said first of all, thanks to my mentorsria Manning from Sigma Prime and Pup from Ethereum Foundation Research and also thanks for to João Oliveira and Jimmy Chen from Sigma Prime who supported me with some of their time and thanks to Anton Lachatiereff from ConsenSys, he spearheaded the technical support in the last couple of weeks. Thanks to EPF organization, to Josh and Mario, thanks to the Ethereum Foundation for hosting the EPF, and thank you to all the fellows, it was really pleasant and great to work with you all. And finally, I'm going to plug my talk tomorrow, or our talk tomorrow, simulating an Ethereum network scale, which will go more into detail on how you can run the simulation yourself. So maybe see some of you there on stage one at 10 past 1 p.m. Thank you for your attention. All right, any questions for Daniel? Hi, just a couple questions. One is when you're making all of these changes to do these simulations, are you actually like updating the client code or is it kind of like network configurations? Yeah, this is like the great advantage to change these or to test these changes, I actually can change just the client. I don't need to develop anything just for that. I changed the actual client, but for the things I showed you, I think I only needed to vary the configuration a bit. But I also did some changes that actually tried to fix these underlying problems in Lighthouse itself. Cool. And then, I guess my other question, so are you starting simulations from, like, a genesis state, or is it, like, a fork of mainnet, and can you do forks of, like, existing networks? Well, I start from a genesis state. My tool supports this. It just does this for us, which is nice. And forking mainnet, I mean, I'm aware that there are shadow forks, they are unrelated to the name of the simulation tool. I haven't tried it. The problem is that the genesis state is quite large, and this might actually be really hard to simulate, like, on a single node. We have all the simulation running on a single server, and that might be hard to have multiple clients in parallel working on that. So I guess it's not really feasible. So I was wondering, once the simulation completes, can we see, like, consolidated metrics on the node or something, like logs, something like that? Very good question. This is how I evaluated those simulations. I kind of forgot to mention that here. The simulation, it is really easy to add a Prometheus node in the simulation configuration, and that automatically gets configured to pull the metrics from all the Lighthouse clients. In the end, we have one huge Prometheus database, which allows us to just pull up some Grafana dashboards or any other analysis. Also, we have all the logs, so we can also look into those if there are any specific nodes that seem to be acting strange or something. Yeah. In fact, you can see every lock of every node. You can see the STDR, but you can see the STD of that other. And in fact, you can see every that the node produced. Right. You can also run a node on a data directory that has been generated by the simulation afterwards. It's a bit weird because the simulation time always takes place in the year 2000, so it's really old data to the node if you start it right now. But you can run that node, and you can attach a block explorer or the explorer, for example, by the panda ops team to it. It's just a bit wonky because of the timing issue. Do you have to like convert the matrix or something like that? So like because the simulation time is less but the time it takes to simulate something is longer time. Do you have to do some conversion to get the matrix or something like that? Yeah, basically the simulation, Shadow starts the simulation time always at the 1st of January in the year 2000. So every time you do a Prometheus query or look into the block explorer, you have to keep in mind that you have to act as if it were the year 2000. Yeah. Any final questions? There are some up there. Oh, we got one more. How is it different from kurtosis? Okay. In a nutshell, kurtosis, you cannot run networks of this scale on a single server with kurtosis because kurtosis is not capable of like pretending to the processes that time is running faster or slower than it actually is basically like having a separated simulation time from real time yeah i would say that is the main difference, that you can scale way higher with Shadow. All right, thanks, Daniel.",
"eventId": "devcon-7",
- "slot_start": 1731482400000,
- "slot_end": 1731484200000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1qlPnS97cEpEKuQEuS06efm97LnehdTDo-7FRoyWVIHY",
+ "slot_start": 1731485700000,
+ "slot_end": 1731486600000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/13dCJ8eFHfsvUgtv1Dz5mrPCKUF6Y5dXPwWu0wN0ixkY",
"resources_slides": null,
"speakers": [
- "michal-zajac"
+ "daniel-knopik"
]
},
"vector": [
@@ -668316,6 +666917,11 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
6,
0,
0,
@@ -668892,6 +667498,14 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -668899,7 +667513,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -669062,6 +667675,20 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -669535,54 +668162,25 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -669641,59 +668239,43 @@
},
{
"session": {
- "id": "security-through-obscurity-using-microdots-to-store-secrets",
- "sourceId": "UHQDPU",
- "title": "Security through obscurity. Using microdots to store secrets.",
- "description": "Key custody remains a tricky problem to solve. Most of the focus around improving the security of key custody revolve around software based approaches like secret sharing. However, physical approaches are also possible. \r\n\r\nThis talk discusses on how to secure secrets using microdots and how microdots may be fabricated at home with legally accessible tools.\r\n\r\nMicrodots is a technique which allows one to shrink documents down. This allows one to embed secrets in documents in plain sight.",
- "track": "Security",
- "type": "Lightning Talk",
+ "id": "simulating-an-ethereum-network-at-scale",
+ "sourceId": "FAZBAD",
+ "title": "Simulating an Ethereum network at scale",
+ "description": "Previously, when Ethereum client developers wanted to test their ideas on the network layer, they either had to use a simulation tool that could be used only with some programming language or had to do network emulation instead, which requires a cluster of computers to do it at scale rather than running it on a laptop-size machine. This talk will tell you how to simulate an Ethereum network with 100+ nodes on a laptop-sized machine with production Ethereum clients.",
+ "track": "Core Protocol",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Lobby",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Digital Sovereignty",
- "Cryptography",
- "Security",
- "Hardware wallets",
- "Custody",
- "Cryptography",
- "Custody",
- "Digital Sovereignty",
- "Hardware wallets",
- "Security"
- ],
"keywords": [
- "None"
+ "Networking",
+ "Simulation"
+ ],
+ "tags": [
+ "Layer 1",
+ "simulation",
+ "Layer",
+ "1"
],
- "duration": 579,
"language": "en",
- "sources_swarmHash": "70b7a1a2acf3ec307ad982db5ea9e354b109ab2b5981ba87ee71c5967e486a52",
- "sources_youtubeId": "3mXa1oeHzzA",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731406200000,
- "slot_end": 1731406800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1zGqyVZiy__TgQYZes9fefN5S6uBUQLT9Yl6wbxjJ-2M",
- "resources_slides": null,
"speakers": [
- "jseam"
- ]
+ "pop",
+ "daniel-knopik"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731564600000,
+ "slot_end": 1731566400000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1x5qwU96CuNwokAG1SeZ9BSYZKjgzyrpzL5MwVOtxJWQ"
},
"vector": [
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -670281,6 +668863,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -670438,7 +669021,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -670451,9 +669033,9 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -670488,7 +669070,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -670517,6 +669098,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -670775,7 +669357,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -670999,11 +669580,12 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -671016,54 +669598,40 @@
0,
0,
0,
- 2
+ 0
]
},
{
"session": {
- "id": "semaphore-v4",
- "sourceId": "ZU9D8U",
- "title": "Semaphore V4",
- "description": "Semaphore is a protocol enabling individuals to prove group membership and send messages (such as votes or endorsements) anonymously. The latest version enhances efficiency and simplifies the use of libraries and contracts. This presentation will cover the new features, project vision, and the importance and challanges of zero-knowledge technologies.",
- "track": "Applied Cryptography",
- "type": "Lightning Talk",
+ "id": "simulating-economic-systems-of-an-autonomous-world",
+ "sourceId": "KWKW3W",
+ "title": "Simulating Economic Systems of an Autonomous World",
+ "description": "This presentation reviews the basics of token systems design and their onchain game applications. This will be specifically tailored to onchain complicated economic systems and simulating them in interactive notebooks for real-time graphing; aiding in parameter tweaking and finding gaps in systems designs. The goal of this talk will be to begin to bridge the gap between complex token systems designers and onchain game designers.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Privacy",
- "Zero-Knowledge",
- "User Experience",
- "proof-of",
- "membership",
- "Privacy",
- "User Experience",
- "Zero-Knowledge"
- ],
"keywords": [
- "semaphore",
- "anonymity sets",
- "proof of membership"
+ "Token Engineering",
+ "Simulations",
+ "Complex Systems"
+ ],
+ "tags": [
+ "Autonomous World",
+ "Gaming",
+ "Protocol Design"
],
- "duration": 1035,
"language": "en",
- "sources_swarmHash": "619dc838e91326f82a78ebd1207f07fa45e9941e162c7999de38f6d08fee6691",
- "sources_youtubeId": "OErC2MyIKjY",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330d403a168eb535f16a2c.vtt",
- "transcript_text": " Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the Ethereum Foundation. And today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Addestation service, SKIMail, TLS Notary, and POP. So some projects can be useful for privacy preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-civil, too. So the three main ideas from this presentation that I would like you to remember are privacy privacy groups can be used to verify credentials to have a better user experience in your applications. Also that you can combine different anti-civil mechanisms to have a stronger one. That's very important. Maybe it's not your case, case for your application, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. Like, this works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes. Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this commitment to a Bandada group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with the members in your group any other questions it's over there I see some people wearing the mere cat hat unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, there might be a reason to remove someone forcefully. Are there any practical way to do that? Yeah, yeah. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is an easy way if you are using code or not. Yeah. Can you explain the mechanic behind, like how can you maintain privacy of everyone and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean, the person, it's a commitment. So people don't know, like, who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and Okay. Thank you, Vivian. Thank you. Our next talk is also going to be about Semaphore v4. So let's welcome our next speaker, Sidur. He's going to show us some new features of Semaphore v4 and some of the importance of the ZK technology. Let's welcome him. Hi. So, hi, folks. I will start introducing myself, and then I'll present some news regarding Semaphore and our future plans. So, I'm Cedar. I work as a software engineer with the PSE team, and in the past years, I have mainly focused on improving the developer experience of some PSE projects. I'm talking about what Semaphore is. Semaphore v4, so some news. And then our roadmap. So, first of all, Semaphore, as far as I know, is one of the simplest client-side zero-log protocols. So the core circuits only contains 22 lines of code without documentation and, like, empty lines. Generating a proof only takes less than one second on browsers, and verifying a proof on-chain only consumes less than 300,000 units of gas, which means, like, around five cents on Arbitrum. But what is it? So Semaphore is a zero-knowledge protocol that allows users to prove their membership in a group and send messages such as votes or feedback without revealing their identity. In addition, it also provides an alifier mechanism to present users from reusing existing proofs. So Semaphore is basically a general-purpose protocol, so you can use it for any use case where you need a layer of privacy. We have been working on Semaphore for a few years now, and we have mainly focused on developer experience until v3 but with the latest version before we also focused on interoperability and efficiency and on-chain costs in particular we have made two important change we have a new identity schema which uses EDDSA keeper and we have optimized the data structure for groups. So let's go a little bit deeper. We replaced the old identity schema with an E-D-D-S-A keeper. E-D-D-S-A is one of the most efficient public key cryptography algorithms using zero-knowledge circuits, and it makes the new version of Sphemafor much more compatible with other existing protocols which use eDSA. In the old schema, the public commitment, which is like the public identifier of the Semaphore identity, was a Poseidon hash of a secret. In the new schema, the public commitment is the Poseidon hash of the eDSA public key. And in addition, it also allows users to sign messages and verify signatures inside and outside ZKey proofs or circuits, which has been and will be hopefully pretty useful for some applications like Zupass, which uses Semaphore v4. So then we optimized the old data structure, the incremental Merkle tree, and we created a new data structure, which is based on the old one,, the incremental Merkle tree. And we created a new data structure, which is based on the old one, the lean incremental Merkle tree. So just small improvements that made it much more efficient, especially when the tree doesn't have many leaves, so for small groups. The key improvements are two. Zero hashes are no longer required. And the tree grows dynamically now. So zero hashes. I just want to show the difference between these two trees. In the old implementation, if the parent node has one child, it will be calculated as the hash of that child node and the zero hash. In the new implementation on the right, the parent node can actually equal the child node itself, so no need to calculate any hash in those cases. The second important change is about the dynamic depth. In the old implementation the tree has a static depth. Each insertion needs to update a number of nodes which equals the static depth of the tree, and in the new implementation, the tree depth grows with the number of leaves, which means each insertion would only require updating a number of nodes proportional to the current number of leaves. So this is quite complex. So please, if you want to know more about this data structure, go to the paper we published a few months ago in the ZKeyKit repository below. Finally, what we would like to do in the next months, we would like to have a new Explorer, which people can use to see on-chain groups, and which admins can use to create and manage groups. We would like to work on a new version of RLN which is pretty similar to Semaphore. They share the same code but RLN works with an additional layer to prevent spam. We would like to add additional tutorials to the documentation and possibly have like specifications for Semaphore v4, something that people ask us a lot of times. We will also explore and consider improving systems, of course, and try to keep ourselves updated on the latest technologies to improve the key requirements of the protocol. So some links you can use to connect and ask us any questions. Yeah, thank you very much Thank You Sidor any questions oh there's one there do you want to give it a go it's on your side hello test thank you for your speech it was good I'm just curious to know more about Semaphore's business model. The tech sounds amazing, but I'm curious, is there a way to generate a profit from this? No. I mean, we are funded by the Thiem Foundation, and we are not thinking about any way to make profit. Okay, thank you. I think we're also not allowed to speak about profits, just from what I heard. Okay, thank you. Hi, I was wondering, to upgrade or migrate from previous version, does that mean like existing project need to generate new identities? 제작진이 새로운 정보를 생성해야 하는 거죠? 네, 새로운 정보를 생성해야 합니다. 그리고 새로운 정보를 생성하는 방법은 세마폴 B4의 정보를 생성하는 것입니다. 그래서, 이전의 정보를 생성하고, 전기 문제를 생성하는 것입니다. and then deriving the private key from the previous secret. I have a question for how the protocol works. Do all the nodes need to be online at the same time? Where are you, sorry. Hi. Sorry. Hi. Hi. Do all the nodes who want to take part in this protocol need to be online at the same time, or is it possible to establish the group without all the participants seeing the other participant at any point in time can you repeat your question sorry about it's about the liveness of the participants yeah so can we establish a semaphore based communication for example even if some of the nodes are only online for a certain short period of time or do they all have to be online at the same time to calculate these secrets yes they have to be online yes on chain at the same time okay thank you Thank you. Any other questions? We have one at the front row here. Hi. Hi, what are the advantages of using the lean IMT now data structure for like the aerodynamic depth of the tree? I think one advantage is that with the old static with the old incremental Merkel tree with static depth we had a range of three of supported three depths from 16 to 32. And even if the group is small, like with 10 members, you had to use a Merkle tree with a static depth which was like 16. So bigger... So it's a storage then? Yes, for storage. And the generation of the proof as well needs more time because the circuits have more constraints. Okay, I see. Thank you. Okay, we still have some time for questions if you have any.",
- "eventId": "devcon-7",
- "slot_start": 1731397200000,
- "slot_end": 1731397800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/12uKp51aS4tQMokLfQJRDQlh518PRLNinkH3148Cq9Do",
- "resources_slides": null,
"speakers": [
- "cedoor"
- ]
+ "nico-rodriguez"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731577800000,
+ "slot_end": 1731579300000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1JGirNWdZq9HEHUw7sdVF-0QUGOk9fJFHX5UmLIB_6hk"
},
"vector": [
0,
@@ -671076,10 +669644,9 @@
0,
0,
0,
- 6,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -671222,6 +669789,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -671661,7 +670229,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -671830,11 +670397,9 @@
0,
0,
0,
- 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -671864,6 +670429,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -671927,6 +670493,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -671934,7 +670502,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -672188,7 +670755,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -672298,7 +670864,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -672383,8 +670948,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -672401,42 +670966,40 @@
},
{
"session": {
- "id": "shadow-network-simulations",
- "sourceId": "H7HCJJ",
- "title": "Shadow Network Simulations",
- "description": "In my EPF project, I implemented Ethshadow, a configuration generator for simulating Ethereum networks using Shadow, and used it to research improvements to the current state of PeerDAS and to estimate the effects of IDONTWANT on node bandwidth. In this presentation, I will present my findings and make a case for testing using Ethshadow.",
- "track": "[CLS] EPF Day",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "id": "singer-sing-writer-hour-with-adegbengaoggunbdeje",
+ "sourceId": "R9KTR7",
+ "title": "Singer sing writer hour with adegbengaoggunbdeje",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Core Protocol",
- "Layer 1",
- "Testing"
- ],
"keywords": [],
- "duration": 936,
+ "tags": [],
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "1jUvR9kBmpg",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67347cd49dbb7a90e16882fa.vtt",
- "transcript_text": " Hi everyone, thank you. My name is Daniel Knopik and I worked on shadow network simulations. The usual clicker problems. Thanks. Yeah. So, in my opinion, network simulations are awesome because they allow testing changes without rolling out to public deaf nets or even test nets which is lower takes synchronization and time and Small local deafness are possible but with a software called shadow We can actually run huge simulations with thousands of nodes. And also with actual clients, like not any code written dedicated to the simulations. So I kind of had a three-phase project. First, I wanted to prepare a tool that allowed me to easily set up these shadow simulations with theorem clients. That is easier said than done because shadow can be kind of finicky sometimes. set up these shadow simulations with theorem clients. That is easier said than done because shadow can be kind of finicky sometimes, so it took a while. Yeah, in the second phase, I want to run experiments specifically on PeerDust and IDon'tWant, also known as GossipSub1.2. And in the third phase, I thought maybe if I saw in the experiments that this is actually a useful tool, I wanted to polish it and actually did, and thus, EthShadow was born. So to sum it up, there are like two main artifacts from my project, the experiment results and ETH Shadow itself. In this presentation, I will kind of focus on my results from PeerDust, and afterwards, also show you slowly or quickly ETH Shadow. Right. So, PeerDust. I won't have time to explain it as fully. So I'm just going to assume there's some awareness of what that is. Um, few points. It's an update to scale blobs and the basic principle is that we want to split the blobs into parts, which we call columns with every note taking custody of some of those columns. And there are some network changes required for this to make sure that the nodes properly distribute the columns across the network, and also so-called super nodes can reconstruct the blobs if they have enough columns. And right now there's like 128 additional subnets in gossip sub which all need to be covered by when a node wants to be proposed, right? We need to get every column out so yeah. Okay so I decided to run some simulations to help the research and development effort. Keep in mind that all results that I present here are like a few months old at this point, so the situation might be better at this point. So my simulation setup involved 1,000 nodes with Reth, Lighthouse, and Lighthouse validator client on each, with 4,000 validators, and in each experiment I simulated 45 minutes of simulated time. For a large simulation like this we want to run on some server that is sufficiently large that the simulation is fast enough for us. And I kind of experimented around a lot to make sure to get like, get nice performance going and kind of settled on a certain instance type you can see it there if you want to run your own simulations with the size and my simulations took a round of four hours per like 45 minutes of simulated time and so the cost of simulation came around at $10. Right. But if you want, like, also run smaller simulations, you can also do this on your laptop. Like, you don't need such a beefy server. This is just, like, my setup for the peer-to-peer simulations. So first I just tried running it on the current implementation in Lighthouse, and the simulated networks quickly fell apart because they lost sync and cannot really sync back up again. And that was kind of similar what was seen on DevNet at the time across basically all clients. So, I thought about how do I measure performance, and I had several metrics, but right here on DevNet at the time across basically all clients. So I thought about how do I measure performance and I had several metrics but right here I will focus on what I call score which is how many slots can over 66% of the network stay in sync. And with the unmodified client with the default configuration, zero. Like immediately after we posted blobs to the network, we lost sync. But I also noticed that if I designate every node as a super node, so custodying all the columns, not just eight or four, then the network stayed stable until the end. So I had the suspicion that something is wrong with the distribution of columns when we just don't broadcast all the columns at all times to everyone. And also that might be something with supernode reconstruction of the blobs might be wrong. Yeah. So, and yeah, the investigation showed that the problem is that if a node could not send all the data out, it would not retry that at all, causing some columns to get lost and custodying nodes for those columns would just not deem the data is available and would just accept the block and the sync and they could not catch up I guess the super nodes were not enough for that. So how do we fix this? I did some simulations where I varied the specs and I did a lot of different variations. I will focus on three here. We could increase the number of peers because if you have more peers, the likelihood that we actually cover all the columns when proposing a block with our peers is higher. So yeah, the base spec or the base configuration in lighthouse looks for 100 peers 150 peers scored 10 with the metric I just mentioned 200 Already 56 and 300 survived the whole simulation so we could see that confirming our theory this improves the situation Next up I increase the number of columns covered per each peer, which should have the same effect, right, because the total number of covered columns also increases with changing this. Increasing from 4 to 8, score 10, and 16 already survived the whole simulation. Finally, there should be an emoji here. The, you know, the diagonal face. All right. Increasing the number of supernodes, which should reconstruct the full blobs, like all columns, if they have half or more. Increasing to 10, scored 0 to 25 of 1,000, right? Scored 2, and 75 also 2. increasing to 10 scored 0 to 25 of thousand right let's go to and 75 also 2 and at that point I didn't test any further because I Want to kind of keep it in? Somewhat realistic scape and I'm not sure how many super notes there will be but we shouldn't in my opinion set the assumption too high all right but we shouldn't, in my opinion, set the assumption too high. All right. If you want to know more about that, there are my weekly reports where I go into a bit more detail. So let's move on to the state of each shadow, like the tool I developed. Because seeing these simulations, I thought, hey, this is kind of useful. I have an iterative approach and can evaluate different configurations. So I spent some weeks in the end to make it available for everyone. And the source is available on GitHub at Ethereum slash ethshadow. Right now there's like first class support for Geth and Lighthouse and there's some experimental support for Reth and Teku. There is some documentation that for Reth and Tiku. There is some documentation that has to be written. For basic use cases, there's good documentation already, so you can check it out. And I think in some cases, usability can be improved. The hard part is that Shadow needs a lot of work for all clients to work in shadow. The reason for that is the technical. Basically we need support from our Linux system calls in shadow. Um, and this is a lot of effort. Unfortunately I, um, kind of won't have much time. So I hope that in the coming Weeks a month I can at least help on the side of it to maintain this But I hope to also get the attention from from the core deaths to help me or help us all Hopefully soon have its shadow for all the clients Okay, there are some things to be said first of all, thanks to my mentorsria Manning from Sigma Prime and Pup from Ethereum Foundation Research and also thanks for to João Oliveira and Jimmy Chen from Sigma Prime who supported me with some of their time and thanks to Anton Lachatiereff from ConsenSys, he spearheaded the technical support in the last couple of weeks. Thanks to EPF organization, to Josh and Mario, thanks to the Ethereum Foundation for hosting the EPF, and thank you to all the fellows, it was really pleasant and great to work with you all. And finally, I'm going to plug my talk tomorrow, or our talk tomorrow, simulating an Ethereum network scale, which will go more into detail on how you can run the simulation yourself. So maybe see some of you there on stage one at 10 past 1 p.m. Thank you for your attention. All right, any questions for Daniel? Hi, just a couple questions. One is when you're making all of these changes to do these simulations, are you actually like updating the client code or is it kind of like network configurations? Yeah, this is like the great advantage to change these or to test these changes, I actually can change just the client. I don't need to develop anything just for that. I changed the actual client, but for the things I showed you, I think I only needed to vary the configuration a bit. But I also did some changes that actually tried to fix these underlying problems in Lighthouse itself. Cool. And then, I guess my other question, so are you starting simulations from, like, a genesis state, or is it, like, a fork of mainnet, and can you do forks of, like, existing networks? Well, I start from a genesis state. My tool supports this. It just does this for us, which is nice. And forking mainnet, I mean, I'm aware that there are shadow forks, they are unrelated to the name of the simulation tool. I haven't tried it. The problem is that the genesis state is quite large, and this might actually be really hard to simulate, like, on a single node. We have all the simulation running on a single server, and that might be hard to have multiple clients in parallel working on that. So I guess it's not really feasible. So I was wondering, once the simulation completes, can we see, like, consolidated metrics on the node or something, like logs, something like that? Very good question. This is how I evaluated those simulations. I kind of forgot to mention that here. The simulation, it is really easy to add a Prometheus node in the simulation configuration, and that automatically gets configured to pull the metrics from all the Lighthouse clients. In the end, we have one huge Prometheus database, which allows us to just pull up some Grafana dashboards or any other analysis. Also, we have all the logs, so we can also look into those if there are any specific nodes that seem to be acting strange or something. Yeah. In fact, you can see every lock of every node. You can see the STDR, but you can see the STD of that other. And in fact, you can see every that the node produced. Right. You can also run a node on a data directory that has been generated by the simulation afterwards. It's a bit weird because the simulation time always takes place in the year 2000, so it's really old data to the node if you start it right now. But you can run that node, and you can attach a block explorer or the explorer, for example, by the panda ops team to it. It's just a bit wonky because of the timing issue. Do you have to like convert the matrix or something like that? So like because the simulation time is less but the time it takes to simulate something is longer time. Do you have to do some conversion to get the matrix or something like that? Yeah, basically the simulation, Shadow starts the simulation time always at the 1st of January in the year 2000. So every time you do a Prometheus query or look into the block explorer, you have to keep in mind that you have to act as if it were the year 2000. Yeah. Any final questions? There are some up there. Oh, we got one more. How is it different from kurtosis? Okay. In a nutshell, kurtosis, you cannot run networks of this scale on a single server with kurtosis because kurtosis is not capable of like pretending to the processes that time is running faster or slower than it actually is basically like having a separated simulation time from real time yeah i would say that is the main difference, that you can scale way higher with Shadow. All right, thanks, Daniel.",
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731485700000,
- "slot_end": 1731486600000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/13dCJ8eFHfsvUgtv1Dz5mrPCKUF6Y5dXPwWu0wN0ixkY",
- "resources_slides": null,
- "speakers": [
- "daniel-knopik"
- ]
+ "slot_start": 1731470400000,
+ "slot_end": 1731474000000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/188EWHuoqMHZmI_lZQs8v-nCOf8dWQUXTZ39BGcW23wE"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 6,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -672452,7 +671015,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -673033,7 +671595,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -673204,11 +671765,9 @@
0,
0,
0,
- 6,
0,
0,
0,
- 2,
0,
0,
0,
@@ -673430,17 +671989,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -673753,8 +672301,6 @@
2,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -673767,41 +672313,49 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "simulating-an-ethereum-network-at-scale",
- "sourceId": "FAZBAD",
- "title": "Simulating an Ethereum network at scale",
- "description": "Previously, when Ethereum client developers wanted to test their ideas on the network layer, they either had to use a simulation tool that could be used only with some programming language or had to do network emulation instead, which requires a cluster of computers to do it at scale rather than running it on a laptop-size machine. This talk will tell you how to simulate an Ethereum network with 100+ nodes on a laptop-sized machine with production Ethereum clients.",
+ "id": "single-slot-finality-and-the-future-of-staking",
+ "sourceId": "LZCP8E",
+ "title": "Single Slot Finality and the future of staking",
+ "description": "Discussing the evolution of the thinking around future upgrades to the Ethereum consensus protocol (single slot finality project) in relationship to the future of staking. For example discussing things like https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928/3",
"track": "Core Protocol",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Networking",
- "Simulation"
+ "Economic",
+ "security"
],
"tags": [
- "Layer 1",
- "simulation",
- "Layer",
- "1"
+ "Core Protocol",
+ "Ethereum Roadmap",
+ "Home staking",
+ "Single-slot Finality",
+ "Consensus Mechanisms",
+ "Security",
+ "economy",
+ "Consensus Mechanisms",
+ "Core Protocol",
+ "Ethereum Roadmap",
+ "Home staking",
+ "Single-slot Finality"
],
"language": "en",
"speakers": [
- "pop",
- "daniel-knopik"
+ "francesco"
],
"eventId": "devcon-7",
- "slot_start": 1731564600000,
- "slot_end": 1731566400000,
+ "slot_start": 1731573600000,
+ "slot_end": 1731575400000,
"slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1x5qwU96CuNwokAG1SeZ9BSYZKjgzyrpzL5MwVOtxJWQ"
+ "resources_presentation": "https://docs.google.com/presentation/d/1198JUW8nHiS-gIHBkbDTKrorHlxq2jJXKTiMaVCMvcI"
},
"vector": [
0,
@@ -674384,6 +672938,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -674400,12 +672955,6 @@
0,
0,
0,
- 6,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -674558,6 +673107,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -674571,12 +673121,12 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -674643,6 +673193,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -674748,7 +673299,9 @@
0,
0,
0,
+ 2,
0,
+ 2,
0,
0,
0,
@@ -674937,6 +673490,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -675037,9 +673591,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -675121,8 +673672,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -675139,40 +673690,44 @@
},
{
"session": {
- "id": "simulating-economic-systems-of-an-autonomous-world",
- "sourceId": "KWKW3W",
- "title": "Simulating Economic Systems of an Autonomous World",
- "description": "This presentation reviews the basics of token systems design and their onchain game applications. This will be specifically tailored to onchain complicated economic systems and simulating them in interactive notebooks for real-time graphing; aiding in parameter tweaking and finding gaps in systems designs. The goal of this talk will be to begin to bridge the gap between complex token systems designers and onchain game designers.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "id": "slangs-query-api-a-better-way-to-analyse-solidity-code",
+ "sourceId": "8PYLB7",
+ "title": "Slang’s Query API: a better way to analyse Solidity code",
+ "description": "Slang is Nomic Foundation’s modular set of Solidity compiler APIs. This presentation will review Slang’s query engine approach to analysing Solidity code, and explain why it makes building tools that support multiple Solidity versions significantly easier than existing solutions, leading overall to higher quality tools.",
+ "track": "Developer Experience",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "expertise": "Expert",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Token Engineering",
- "Simulations",
- "Complex Systems"
+ "Parsing",
+ "Compiling"
],
"tags": [
- "Autonomous World",
- "Gaming",
- "Protocol Design"
+ "Developer Infrastructure",
+ "Tooling",
+ "Languages",
+ "compilers",
+ "Developer Infrastructure",
+ "Languages",
+ "Tooling"
],
"language": "en",
"speakers": [
- "nico-rodriguez"
+ "antony-blakey"
],
"eventId": "devcon-7",
- "slot_start": 1731577800000,
- "slot_end": 1731579300000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1JGirNWdZq9HEHUw7sdVF-0QUGOk9fJFHX5UmLIB_6hk"
+ "slot_start": 1731648600000,
+ "slot_end": 1731650400000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1y7kvxWFxGZ-TBTEld48n6Dz0MGYoIGHria1lhFAdTZo"
},
"vector": [
0,
0,
0,
+ 6,
0,
0,
0,
@@ -675182,8 +673737,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -675326,7 +673879,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -675765,6 +674317,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -675941,6 +674494,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -675968,12 +674522,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -676016,6 +674570,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -676032,8 +674587,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -676148,6 +674701,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -676484,10 +675038,6 @@
0,
0,
2,
- 0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -676500,30 +675050,38 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "singer-sing-writer-hour-with-adegbengaoggunbdeje",
- "sourceId": "R9KTR7",
- "title": "Singer sing writer hour with adegbengaoggunbdeje",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
- "audience": "Engineering",
+ "id": "small-brain-games-mud-day-demo",
+ "sourceId": "9ZBKKS",
+ "title": "Small Brain Games - MUD Day Demo",
+ "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nFor the past 1.5 years, I've been building fully onchain games–games where the entire state is onchain for some reason (have launched 7!). In this demo, I will showcase some of these games that I have built.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
"keywords": [],
- "tags": [],
+ "tags": [
+ "Gaming",
+ "Autonomous World",
+ "Autonomous World",
+ "Gaming"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "small-brain"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731470400000,
- "slot_end": 1731474000000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/188EWHuoqMHZmI_lZQs8v-nCOf8dWQUXTZ39BGcW23wE"
+ "slot_start": 1731557700000,
+ "slot_end": 1731558000000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1rEXXVcN2oqvYGgP1WxdgoBQUTVgnEnjAZjAEYHOPJv8"
},
"vector": [
0,
@@ -676535,15 +675093,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -676672,6 +675225,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -677389,6 +675943,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -677843,11 +676399,10 @@
2,
0,
0,
- 2,
- 0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -677861,76 +676416,35 @@
},
{
"session": {
- "id": "single-slot-finality-and-the-future-of-staking",
- "sourceId": "LZCP8E",
- "title": "Single Slot Finality and the future of staking",
- "description": "Discussing the evolution of the thinking around future upgrades to the Ethereum consensus protocol (single slot finality project) in relationship to the future of staking. For example discussing things like https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928/3",
- "track": "Core Protocol",
+ "id": "smart-accounts-need-smart-sessions",
+ "sourceId": "SJDY99",
+ "title": "Smart Accounts need Smart Sessions",
+ "description": "The world of dapps is evolving and wallets are becoming smarter. This is powered by developments in Smart Accounts which unlock more user-friendly experiences. Learn about how WalletConnect is introducing Smart Sessions and walkthrough all the standards (EIPs, ERCs and CAIPs) that will make the future of wallet UX possible.",
+ "track": "Usability",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Economic",
- "security"
+ "standards",
+ "wallets",
+ "interoperability"
],
"tags": [
- "Core Protocol",
- "Ethereum Roadmap",
- "Home staking",
- "Single-slot Finality",
- "Consensus Mechanisms",
- "Security",
- "economy",
- "Consensus Mechanisms",
- "Core Protocol",
- "Ethereum Roadmap",
- "Home staking",
- "Single-slot Finality"
+ "interoperability"
],
"language": "en",
"speakers": [
- "francesco"
+ "pedro-gomes"
],
"eventId": "devcon-7",
- "slot_start": 1731573600000,
- "slot_end": 1731575400000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1198JUW8nHiS-gIHBkbDTKrorHlxq2jJXKTiMaVCMvcI"
+ "slot_start": 1731552300000,
+ "slot_end": 1731554100000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Xn-t83UrHqZiD2z9Y1uuRL-w6SCGvLF-dX6-cK0TwYM"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -677939,6 +676453,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -678485,7 +677000,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -678525,6 +677039,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -678652,7 +677167,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -678671,7 +677185,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -678729,7 +677242,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -678738,7 +677250,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -678844,9 +677355,7 @@
0,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
@@ -679036,7 +677545,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -679077,6 +677585,36 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -679213,7 +677751,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -679222,6 +677759,11 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -679235,50 +677777,46 @@
},
{
"session": {
- "id": "slangs-query-api-a-better-way-to-analyse-solidity-code",
- "sourceId": "8PYLB7",
- "title": "Slang’s Query API: a better way to analyse Solidity code",
- "description": "Slang is Nomic Foundation’s modular set of Solidity compiler APIs. This presentation will review Slang’s query engine approach to analysing Solidity code, and explain why it makes building tools that support multiple Solidity versions significantly easier than existing solutions, leading overall to higher quality tools.",
- "track": "Developer Experience",
+ "id": "smart-contracts-with-privacy-case-study-buying-renewable-power",
+ "sourceId": "F9PWUP",
+ "title": "Smart Contracts with Privacy - Case Study - Buying Renewable Power",
+ "description": "Getting the world’s industries to switch to renewable power is immensely important for our planet’s future, but renewable power purchasing agreements turn out to be complicated to manage and administer. Buyers and sellers must interact indirectly through the electricity market and agreements contain complex rules. Keeping track of these is complicated and expensive - UNLESS you have a blockchain-based smart contract. This is how we did it, using ZK for privacy, on chain!",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Expert",
- "audience": "Engineering",
+ "expertise": "Intermediate",
+ "audience": "Business",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Parsing",
- "Compiling"
+ "Enterprise"
],
"tags": [
- "Developer Infrastructure",
- "Tooling",
- "Languages",
- "compilers",
- "Developer Infrastructure",
- "Languages",
- "Tooling"
+ "Privacy",
+ "Zero-Knowledge",
+ "Use Cases",
+ "enterprise",
+ "Privacy",
+ "Use Cases",
+ "Zero-Knowledge"
],
"language": "en",
"speakers": [
- "antony-blakey"
+ "paul-brody"
],
"eventId": "devcon-7",
- "slot_start": 1731648600000,
- "slot_end": 1731650400000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1y7kvxWFxGZ-TBTEld48n6Dz0MGYoIGHria1lhFAdTZo"
+ "slot_start": 1731493800000,
+ "slot_end": 1731495600000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1iPCFSCb5vpiqtzwoYxszBwbVcjQ5iI86jv7FH1Uo3E8"
},
"vector": [
- 0,
- 0,
- 0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -680033,6 +678571,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -680042,7 +678581,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -680075,7 +678613,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -680101,6 +678638,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -680118,7 +678656,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -680138,6 +678675,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -680250,7 +678788,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -680501,6 +679038,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -680582,14 +679120,14 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
- 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -680604,41 +679142,53 @@
},
{
"session": {
- "id": "small-brain-games-mud-day-demo",
- "sourceId": "9ZBKKS",
- "title": "Small Brain Games - MUD Day Demo",
- "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nFor the past 1.5 years, I've been building fully onchain games–games where the entire state is onchain for some reason (have launched 7!). In this demo, I will showcase some of these games that I have built.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "id": "solarpunk-vs-lunarpunk-the-evolution-and-integration-of-these-movements",
+ "sourceId": "SFY3FB",
+ "title": "Solarpunk vs. Lunarpunk: The Evolution and Integration of these Movements",
+ "description": "In this talk, I will explore how the ideals of solarpunk and lunarpunk can be integrated to address privacy, inclusivity, and justice. We will explain how combining the strengths of both movements we can potentially create a cohesive vision for a sustainable, equitable, and free future.",
+ "track": "Cypherpunk & Privacy",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Product",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [],
"tags": [
- "Gaming",
- "Autonomous World",
- "Autonomous World",
- "Gaming"
+ "Coordination",
+ "Anonymity",
+ "Solarpunk",
+ "Ethereum for Good",
+ "Social",
+ "culture",
+ "Anonymity",
+ "Coordination",
+ "Ethereum for Good",
+ "Social",
+ "Solarpunk"
],
- "language": "en",
- "speakers": [
- "small-brain"
+ "keywords": [
+ "Lunarpunk",
+ "Culture"
],
+ "duration": 567,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "2SYWYVJonuk",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": "6734a1589dbb7a90e1486e16",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734a1589dbb7a90e1486e16.vtt",
+ "transcript_text": " Hello everyone. Thanks for coming today. I'm going to talk a little bit about the solar punk versus lunar punk, the evolution and integration of these movements. So before we talk about solar punk and lunar punk, maybe we go a little bit on history. Actually thanks to the NIMH guys, yesterday they did a sick presentation about the punk movement. Thank you for that, shout out to them. So yeah, let's start very quickly here. So the punk movement in the late 60s and the mid-70s actually started as a music movement. Who knew here that actually the punk movement was a music movement? Okay, perfect. There's a lot of people that do know that, which is really good. What happened there is that there were people that were a little bit depressed because, or not depressed, just not happy with the state of the rock scene. The rock scene became a very commercialized thing. So the punks, they were against this commercialization. They were against all this mainstream and this anti-establishment. They were like basically anti-establishment. So they came up together and they started to create their own environments. They started to create their own culture. They started to create their own way of dressing up. They started to create their own ideals and so on. And the main ethos of the punk movement was do it your own ethic. Valuing the self-expression, the personal responsibility, and the direct action. Then, after that, we had in the early 80s, we had the cyberpunk movement. And the cyberpunk movement was, it started first like a sci-fi type of thing. So basically, someone, I don't remember exactly the name, wrote a novel about cyberpunk. And cyberpunk started to be mentioned more and more in literature in the early 80s. These sci-fi stories that were being created were basically anti-authoritarianism and kind of like showing like a resistance against the state or against like any form of coercion. And yeah, another thing that is important to mention about the cyberpunk movement was that this, let's say, movement was created thanks to a lot of literature, a lot of movies like Blade Runner and more and more and more, more, let's say, films and different, let's say, forms of media that was basically showing to the world that we're going to be living in a world where where there's going to be a lot of oppression and that there's going to be a lot of oppression and there's going to be a lot of control by the different organizations. And not necessarily the state, but actually the corporations. Then, in the late 80s, there was also, again, a new sci-fi term that came up, which was steampunk. And the steampunk was kind of weird because it came after the cyberpunk. The steampunk, it came after the cyberpunk. Again the cyberpunk was like this idea, this futuristic dystopian scenario where you know corporations were going to attack the individuals and basically were going to be surveilled and so on. In the steampunk, they were imagining themselves, even though they happened in the 80s, they were imagining themselves that they were in the Victorian era and that they were imagining in the future how, let's say, the steampunk type of culture would look like. The steampunk, for those that are not aware, they usually use a lot of gears, a lot of mechanical things. If you Google quickly steampunk, you probably see that a lot of people have been going to festivals with this type of, let's say, how would I call it, aesthetic. Then the cypherpunk. The cypherpunk came in the early 80s, and basically was with the idea of creating more encryption and creating, let's say, more tools that would allow people to communicate directly to each other, end to end. And yeah, yeah basically the main ethos is privacy, freedom through encryption and digital autonomy. Then came up the solar punk movement and the solar punk movement was in the mid 2010s and the idea of the solar punk movement was basically to have kind of like a more optimistic view of the future and how we can use technology for the betterment of humanity and then uh later on in 2020s uh the lunar punk movement came out which was a movement which is a movement that was basically uh around a lot of mysticism uh when it comes to um privacy and also um the balance between the light and the dark or the shadows or what they call it the dark forest and this movement emphasizes cryptography and privacy tools this is the first video that actually explained a lot about the rise of the lunar punk. I'm not going to show you the video because I don't have time, but afterwards I'm going to share with you the slides so you guys can see. But one of the things that they say in the video is that solar punk hackers are creating transparent infrastructure for funding public goods. And that was kind of like one of the things that they said that is not necessarily good. Also, that the Lunar Pong has been forced to break away from the Solar Pong legacy, which is basically all of this technology with Ethereum that is very transparent and very open for everyone. And, yeah, basically I started tweeting to the people that created this video and say, hey, actually I find that you guys are kind of like being a little bit populist and using a narrative against the solar punks, when in reality, a lot of the solar punks, we do care about privacy. And actually, Rachel, who is the person that is behind the lunar punk movement, she started replying to the tweets and saying, well, the article is merely pointing out authoritarian tendency within the Solarpunk ecosystem. And yeah, basically she was saying that proof of humanity and Gitcoin are not necessarily really aligned with our values. Here there's also a video that talks Solarp Punk versus Lunar Punk with Kevin Iwaki. Also we have it in the slides, you guys can check it afterwards. And yeah, basically what happened afterwards is that when we started having this conversation with Rose, we realized that a lot of the things that the Lunar Punks believe are very similar to the things that the solar punks believe. I myself, I was calling myself a solar punk for a lot of years until this new, let's say, narrative of the lunar punk came out. When this new narrative came out, I stopped calling myself a solar punk because it was not really clear what a solar punk was and so on. And I'm saying all of this to you guys is because it's important to understand that we are creating these movements. We are creating them using language and using, let's say, narratives. So that means that we need to be very aware and very conscious of the language that we use when we're creating these different type of movements. So as I said before, we realize that a lot of the values that the lunar punks said that they have and the values that I consider that I had as a solar punk are actually very similar. But if we extrapolate all of the things that the solar punk or lunar punks are saying, one thing we have in common is that the solar punk, cypher punks, cyber punks, or any of those punks' movement, the only thing that they care about was protecting their community and having a better world for their community and having a better world for their community and for their humanity. So again, if we extrapolate all of the differences between all of these different movements, the main common denominator is that word, care. They care about their communities. So what is the highest form of care? To me, that's love. And that's basically why I'm calling myself a love punk. And that's it for today. If you guys want to learn more about the presentation, there's a lot of videos there, very informative videos. Check out the QR code and connect with me. And yeah, let's chat more about it.",
"eventId": "devcon-7",
- "slot_start": 1731557700000,
- "slot_end": 1731558000000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1rEXXVcN2oqvYGgP1WxdgoBQUTVgnEnjAZjAEYHOPJv8"
+ "slot_start": 1731496800000,
+ "slot_end": 1731497400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Zg48147sw4ud8uPsdsYKyuXSSdSVDoJZ0LSxumOJZ4o",
+ "resources_slides": null,
+ "speakers": [
+ "manualzuru"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -680774,7 +679324,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -681236,6 +679785,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -681414,6 +679964,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -681494,8 +680045,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -681514,6 +680063,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -681542,6 +680093,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -681566,6 +680118,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -681619,6 +680172,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -681953,8 +680507,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -681967,40 +680521,37 @@
},
{
"session": {
- "id": "smart-accounts-need-smart-sessions",
- "sourceId": "SJDY99",
- "title": "Smart Accounts need Smart Sessions",
- "description": "The world of dapps is evolving and wallets are becoming smarter. This is powered by developments in Smart Accounts which unlock more user-friendly experiences. Learn about how WalletConnect is introducing Smart Sessions and walkthrough all the standards (EIPs, ERCs and CAIPs) that will make the future of wallet UX possible.",
- "track": "Usability",
+ "id": "solidity-inline-assembly-for-developer-experience",
+ "sourceId": "F7XJZW",
+ "title": "Solidity Inline-Assembly for Developer Experience",
+ "description": "We demonstrate how inline-assembly is used at Solady to improve the account abstraction developer experience, write concise code, and create novel features.\r\n\r\nSolady is a Solidity library (MIT-licensed). \r\n\r\nSome of our biggest users include Coinbase, Optimism, Uniswap.",
+ "track": "Developer Experience",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developper",
"featured": false,
"doNotRecord": false,
"keywords": [
- "standards",
- "wallets",
- "interoperability"
+ "Solidity"
],
"tags": [
- "interoperability"
+ "Gas",
+ "Account Abstraction",
+ "solidity",
+ "Account Abstraction",
+ "Gas"
],
"language": "en",
"speakers": [
- "pedro-gomes"
+ "vectorized"
],
"eventId": "devcon-7",
- "slot_start": 1731552300000,
- "slot_end": 1731554100000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1Xn-t83UrHqZiD2z9Y1uuRL-w6SCGvLF-dX6-cK0TwYM"
+ "slot_start": 1731576600000,
+ "slot_end": 1731578400000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ww4IN7FSAReDpOBeMK96jT38LWmsqkRdbQBoBnUIH-k"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -682595,10 +681146,10 @@
0,
0,
0,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -682801,6 +681352,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -682976,6 +681528,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -683111,6 +681664,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -683140,7 +681694,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -683313,7 +681866,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -683322,6 +681874,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -683331,46 +681884,46 @@
},
{
"session": {
- "id": "smart-contracts-with-privacy-case-study-buying-renewable-power",
- "sourceId": "F9PWUP",
- "title": "Smart Contracts with Privacy - Case Study - Buying Renewable Power",
- "description": "Getting the world’s industries to switch to renewable power is immensely important for our planet’s future, but renewable power purchasing agreements turn out to be complicated to manage and administer. Buyers and sellers must interact indirectly through the electricity market and agreements contain complex rules. Keeping track of these is complicated and expensive - UNLESS you have a blockchain-based smart contract. This is how we did it, using ZK for privacy, on chain!",
- "track": "Real World Ethereum",
+ "id": "solidity-then-now-and-the-future",
+ "sourceId": "HZ3DEF",
+ "title": "Solidity: Then, Now, & the Future!",
+ "description": "In this talk, I will be presenting the prospect of Q1 2025 release of the Solidity language compiler including the following sections:\r\n\r\n- Latest features and developments\r\n- via-ir: what's happening and what's next\r\n- Experimental Solidity: The future of the language\r\n- Timeline & roadmap",
+ "track": "Developer Experience",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Business",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Enterprise"
+ "Smart Contract Development",
+ "Solidity"
],
"tags": [
- "Privacy",
- "Zero-Knowledge",
- "Use Cases",
- "enterprise",
- "Privacy",
- "Use Cases",
- "Zero-Knowledge"
+ "Tooling",
+ "Languages",
+ "solidity",
+ "Languages",
+ "Tooling"
],
"language": "en",
"speakers": [
- "paul-brody"
+ "vishwa-mehta"
],
"eventId": "devcon-7",
- "slot_start": 1731493800000,
- "slot_end": 1731495600000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1iPCFSCb5vpiqtzwoYxszBwbVcjQ5iI86jv7FH1Uo3E8"
+ "slot_start": 1731574800000,
+ "slot_end": 1731576600000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1GmwHGEiPwMU4yfyA7ipBeOYh8M7CK0BgtepZdbx3JFA"
},
"vector": [
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -683961,10 +682514,10 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -684128,12 +682681,12 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -684195,7 +682748,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -684210,6 +682762,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -684232,7 +682785,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -684476,6 +683028,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -684598,7 +683151,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -684674,6 +683226,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -684684,10 +683237,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -684699,58 +683248,44 @@
},
{
"session": {
- "id": "solarpunk-vs-lunarpunk-the-evolution-and-integration-of-these-movements",
- "sourceId": "SFY3FB",
- "title": "Solarpunk vs. Lunarpunk: The Evolution and Integration of these Movements",
- "description": "In this talk, I will explore how the ideals of solarpunk and lunarpunk can be integrated to address privacy, inclusivity, and justice. We will explain how combining the strengths of both movements we can potentially create a cohesive vision for a sustainable, equitable, and free future.",
- "track": "Cypherpunk & Privacy",
+ "id": "solo-staking-in-the-dark-forest-a-survival-guide",
+ "sourceId": "REJ3SW",
+ "title": "Solo staking in the dark forest: a survival guide",
+ "description": "Solo stakers are key to keeping the Ethereum ecosystem geographically decentralized and censorship resistant. But PBS leaves solo stakers extremely vulnerable to a variety of narrowly targeted DDOS attacks, made possible by public information on the p2p network. This talk will explain why privacy matters on the p2p layer, provide an overview of the attacks solo stakers would face in PBS, and demonstrate some of these in a sandbox environment.",
+ "track": "Core Protocol",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Stakers/Validators",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Coordination",
- "Anonymity",
- "Solarpunk",
- "Ethereum for Good",
- "Social",
- "culture",
- "Anonymity",
- "Coordination",
- "Ethereum for Good",
- "Social",
- "Solarpunk"
- ],
"keywords": [
- "Lunarpunk",
- "Culture"
+ "Metadata"
+ ],
+ "tags": [
+ "Staking",
+ "Privacy",
+ "Security",
+ "MEV",
+ "metadata",
+ "MEV",
+ "Privacy",
+ "Security"
],
- "duration": 567,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "2SYWYVJonuk",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": "6734a1589dbb7a90e1486e16",
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734a1589dbb7a90e1486e16.vtt",
- "transcript_text": " Hello everyone. Thanks for coming today. I'm going to talk a little bit about the solar punk versus lunar punk, the evolution and integration of these movements. So before we talk about solar punk and lunar punk, maybe we go a little bit on history. Actually thanks to the NIMH guys, yesterday they did a sick presentation about the punk movement. Thank you for that, shout out to them. So yeah, let's start very quickly here. So the punk movement in the late 60s and the mid-70s actually started as a music movement. Who knew here that actually the punk movement was a music movement? Okay, perfect. There's a lot of people that do know that, which is really good. What happened there is that there were people that were a little bit depressed because, or not depressed, just not happy with the state of the rock scene. The rock scene became a very commercialized thing. So the punks, they were against this commercialization. They were against all this mainstream and this anti-establishment. They were like basically anti-establishment. So they came up together and they started to create their own environments. They started to create their own culture. They started to create their own way of dressing up. They started to create their own ideals and so on. And the main ethos of the punk movement was do it your own ethic. Valuing the self-expression, the personal responsibility, and the direct action. Then, after that, we had in the early 80s, we had the cyberpunk movement. And the cyberpunk movement was, it started first like a sci-fi type of thing. So basically, someone, I don't remember exactly the name, wrote a novel about cyberpunk. And cyberpunk started to be mentioned more and more in literature in the early 80s. These sci-fi stories that were being created were basically anti-authoritarianism and kind of like showing like a resistance against the state or against like any form of coercion. And yeah, another thing that is important to mention about the cyberpunk movement was that this, let's say, movement was created thanks to a lot of literature, a lot of movies like Blade Runner and more and more and more, more, let's say, films and different, let's say, forms of media that was basically showing to the world that we're going to be living in a world where where there's going to be a lot of oppression and that there's going to be a lot of oppression and there's going to be a lot of control by the different organizations. And not necessarily the state, but actually the corporations. Then, in the late 80s, there was also, again, a new sci-fi term that came up, which was steampunk. And the steampunk was kind of weird because it came after the cyberpunk. The steampunk, it came after the cyberpunk. Again the cyberpunk was like this idea, this futuristic dystopian scenario where you know corporations were going to attack the individuals and basically were going to be surveilled and so on. In the steampunk, they were imagining themselves, even though they happened in the 80s, they were imagining themselves that they were in the Victorian era and that they were imagining in the future how, let's say, the steampunk type of culture would look like. The steampunk, for those that are not aware, they usually use a lot of gears, a lot of mechanical things. If you Google quickly steampunk, you probably see that a lot of people have been going to festivals with this type of, let's say, how would I call it, aesthetic. Then the cypherpunk. The cypherpunk came in the early 80s, and basically was with the idea of creating more encryption and creating, let's say, more tools that would allow people to communicate directly to each other, end to end. And yeah, yeah basically the main ethos is privacy, freedom through encryption and digital autonomy. Then came up the solar punk movement and the solar punk movement was in the mid 2010s and the idea of the solar punk movement was basically to have kind of like a more optimistic view of the future and how we can use technology for the betterment of humanity and then uh later on in 2020s uh the lunar punk movement came out which was a movement which is a movement that was basically uh around a lot of mysticism uh when it comes to um privacy and also um the balance between the light and the dark or the shadows or what they call it the dark forest and this movement emphasizes cryptography and privacy tools this is the first video that actually explained a lot about the rise of the lunar punk. I'm not going to show you the video because I don't have time, but afterwards I'm going to share with you the slides so you guys can see. But one of the things that they say in the video is that solar punk hackers are creating transparent infrastructure for funding public goods. And that was kind of like one of the things that they said that is not necessarily good. Also, that the Lunar Pong has been forced to break away from the Solar Pong legacy, which is basically all of this technology with Ethereum that is very transparent and very open for everyone. And, yeah, basically I started tweeting to the people that created this video and say, hey, actually I find that you guys are kind of like being a little bit populist and using a narrative against the solar punks, when in reality, a lot of the solar punks, we do care about privacy. And actually, Rachel, who is the person that is behind the lunar punk movement, she started replying to the tweets and saying, well, the article is merely pointing out authoritarian tendency within the Solarpunk ecosystem. And yeah, basically she was saying that proof of humanity and Gitcoin are not necessarily really aligned with our values. Here there's also a video that talks Solarp Punk versus Lunar Punk with Kevin Iwaki. Also we have it in the slides, you guys can check it afterwards. And yeah, basically what happened afterwards is that when we started having this conversation with Rose, we realized that a lot of the things that the Lunar Punks believe are very similar to the things that the solar punks believe. I myself, I was calling myself a solar punk for a lot of years until this new, let's say, narrative of the lunar punk came out. When this new narrative came out, I stopped calling myself a solar punk because it was not really clear what a solar punk was and so on. And I'm saying all of this to you guys is because it's important to understand that we are creating these movements. We are creating them using language and using, let's say, narratives. So that means that we need to be very aware and very conscious of the language that we use when we're creating these different type of movements. So as I said before, we realize that a lot of the values that the lunar punks said that they have and the values that I consider that I had as a solar punk are actually very similar. But if we extrapolate all of the things that the solar punk or lunar punks are saying, one thing we have in common is that the solar punk, cypher punks, cyber punks, or any of those punks' movement, the only thing that they care about was protecting their community and having a better world for their community and having a better world for their community and for their humanity. So again, if we extrapolate all of the differences between all of these different movements, the main common denominator is that word, care. They care about their communities. So what is the highest form of care? To me, that's love. And that's basically why I'm calling myself a love punk. And that's it for today. If you guys want to learn more about the presentation, there's a lot of videos there, very informative videos. Check out the QR code and connect with me. And yeah, let's chat more about it.",
+ "speakers": [
+ "qianchen-q-yu"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731496800000,
- "slot_end": 1731497400000,
+ "slot_start": 1731639900000,
+ "slot_end": 1731640500000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Zg48147sw4ud8uPsdsYKyuXSSdSVDoJZ0LSxumOJZ4o",
- "resources_slides": null,
- "speakers": [
- "manualzuru"
- ]
+ "resources_presentation": "https://docs.google.com/presentation/d/1d-GmGcNLmt1uMkzzdpBPgSsDGcejG31g_wfOtXcVIvg"
},
"vector": [
0,
0,
0,
0,
- 0,
6,
0,
0,
@@ -685346,7 +683881,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -685497,6 +684031,9 @@
0,
0,
0,
+ 6,
+ 0,
+ 6,
0,
0,
0,
@@ -685524,7 +684061,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -685611,6 +684147,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -685624,7 +684161,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -685653,8 +684189,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -685678,7 +684212,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -685733,7 +684266,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -685979,6 +684511,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -686068,8 +684601,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -686081,10 +684614,10 @@
},
{
"session": {
- "id": "solidity-inline-assembly-for-developer-experience",
- "sourceId": "F7XJZW",
- "title": "Solidity Inline-Assembly for Developer Experience",
- "description": "We demonstrate how inline-assembly is used at Solady to improve the account abstraction developer experience, write concise code, and create novel features.\r\n\r\nSolady is a Solidity library (MIT-licensed). \r\n\r\nSome of our biggest users include Coinbase, Optimism, Uniswap.",
+ "id": "solving-multichain-ux-lessons-from-cosmos-for-the-rollup-ecosystem",
+ "sourceId": "QKRCF7",
+ "title": "Solving Multichain UX: Lessons from Cosmos for the Rollup Ecosystem",
+ "description": "This talk addresses how we tackled challenges in the Cosmos ecosystem like liquidity fragmentation, multi-chain accounts, and cross-chain contract standards, and how these solutions can be used to improve cross-chain UX in the rollup ecosystem. \r\n\r\nIf time allows, we'll also dig into designing flexible and scalable abstractions for rapid deployment of integrations (bridges, dexs, wallets) across not just many chains, but many diverse tech stacks.",
"track": "Developer Experience",
"type": "Talk",
"expertise": "Intermediate",
@@ -686092,24 +684625,30 @@
"featured": false,
"doNotRecord": false,
"keywords": [
- "Solidity"
+ "DeFi",
+ "Cross-chain",
+ "Aggregation"
],
"tags": [
- "Gas",
+ "Fragmentation",
+ "UI/UX",
"Account Abstraction",
- "solidity",
+ "defi",
+ "cross-chain",
+ "aggregation",
"Account Abstraction",
- "Gas"
+ "Fragmentation",
+ "UI/UX"
],
"language": "en",
"speakers": [
- "vectorized"
+ "sunny-aggarwal"
],
"eventId": "devcon-7",
- "slot_start": 1731576600000,
- "slot_end": 1731578400000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1ww4IN7FSAReDpOBeMK96jT38LWmsqkRdbQBoBnUIH-k"
+ "slot_start": 1731577800000,
+ "slot_end": 1731579600000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/10vnF2ObOK5u8Z8XcfbB0o6Q0DIS1LwGHZA_ieNhsIXg"
},
"vector": [
0,
@@ -686712,8 +685251,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -686906,8 +685443,7 @@
0,
0,
0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -686923,6 +685459,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -687054,6 +685591,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -687092,9 +685630,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -687228,7 +685763,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -687338,6 +685872,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -687346,6 +685881,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -687447,46 +685983,48 @@
},
{
"session": {
- "id": "solidity-then-now-and-the-future",
- "sourceId": "HZ3DEF",
- "title": "Solidity: Then, Now, & the Future!",
- "description": "In this talk, I will be presenting the prospect of Q1 2025 release of the Solidity language compiler including the following sections:\r\n\r\n- Latest features and developments\r\n- via-ir: what's happening and what's next\r\n- Experimental Solidity: The future of the language\r\n- Timeline & roadmap",
- "track": "Developer Experience",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "sovereignists-vs-globalists",
+ "sourceId": "ZHQPKA",
+ "title": "Sovereignists vs. Globalists",
+ "description": "Sovereignists vs. Globalists is the real battle we should be fighting.\r\n\r\nFundamentally the goal of the space is to be Sovereign. I think very few people came into the space with the idea that well we should all rely on a single, one World government to control everything we do. But rather how do we give users a choice about what kind of systems they actually interact with on a day-to-day basis.\r\n\r\nWhat we should be thinking about when building truly decentralized truly resilient systems, is how to",
+ "track": "Cypherpunk & Privacy",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Smart Contract Development",
- "Solidity"
+ "Vision",
+ "future",
+ "resilient technologies"
],
"tags": [
- "Tooling",
- "Languages",
- "solidity",
- "Languages",
- "Tooling"
+ "Decentralization Improvements",
+ "Digital Sovereignty",
+ "Emergency Plan",
+ "resiliency",
+ "technology",
+ "Decentralization Improvements",
+ "Digital Sovereignty",
+ "Emergency Plan"
],
"language": "en",
"speakers": [
- "vishwa-mehta"
+ "adrian-brink"
],
"eventId": "devcon-7",
- "slot_start": 1731574800000,
- "slot_end": 1731576600000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1GmwHGEiPwMU4yfyA7ipBeOYh8M7CK0BgtepZdbx3JFA"
+ "slot_start": 1731648600000,
+ "slot_end": 1731649200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Ce0TClLRzVeI_KHk3Q7wjGn9iUM0mxltuQHeo2UgQuw"
},
"vector": [
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -688236,6 +686774,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -688252,8 +686791,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -688281,6 +686818,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -688328,7 +686866,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -688392,6 +686929,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -688434,6 +686972,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -688595,7 +687134,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -688615,6 +687153,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -688796,12 +687335,10 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -688814,40 +687351,42 @@
},
{
"session": {
- "id": "solo-staking-in-the-dark-forest-a-survival-guide",
- "sourceId": "REJ3SW",
- "title": "Solo staking in the dark forest: a survival guide",
- "description": "Solo stakers are key to keeping the Ethereum ecosystem geographically decentralized and censorship resistant. But PBS leaves solo stakers extremely vulnerable to a variety of narrowly targeted DDOS attacks, made possible by public information on the p2p network. This talk will explain why privacy matters on the p2p layer, provide an overview of the attacks solo stakers would face in PBS, and demonstrate some of these in a sandbox environment.",
- "track": "Core Protocol",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Stakers/Validators",
+ "id": "speed-hacking-challenge",
+ "sourceId": "RSYU7K",
+ "title": "Speed Hacking Challenge",
+ "description": "Prize Pool: $50,000\r\n\r\nA High-Stakes Speed Hacking/ CTF Challenge\r\nAre you ready to dive headfirst into a thrilling web3 adventure? Join us for ETH Escape, a heart-pounding Speed Hacking & Capture the Flag (CTF) challenge designed to test your coding skills and problem-solving abilities on Ethereum.\r\n\r\nhttps://lu.ma/viyjky8t",
+ "track": "[CLS] ETH Escape - Speed Hacking Challenge",
+ "type": "Mixed Formats",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Metadata"
- ],
- "tags": [
- "Staking",
- "Privacy",
- "Security",
- "MEV",
- "metadata",
- "MEV",
- "Privacy",
- "Security"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "qianchen-q-yu"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731639900000,
- "slot_end": 1731640500000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1d-GmGcNLmt1uMkzzdpBPgSsDGcejG31g_wfOtXcVIvg"
+ "slot_start": 1731551400000,
+ "slot_end": 1731573000000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1TFlUSOJNbrhtdG-u3_ajWbpR--vyfBXX6KSwtcFkFI0"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -689452,7 +687991,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -689600,9 +688138,7 @@
0,
0,
0,
- 6,
0,
- 6,
0,
0,
0,
@@ -689716,7 +688252,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -689729,7 +688264,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -690083,22 +688617,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -690163,6 +688681,11 @@
0,
0,
0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
2,
0,
0,
@@ -690171,8 +688694,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -690183,47 +688704,39 @@
},
{
"session": {
- "id": "solving-multichain-ux-lessons-from-cosmos-for-the-rollup-ecosystem",
- "sourceId": "QKRCF7",
- "title": "Solving Multichain UX: Lessons from Cosmos for the Rollup Ecosystem",
- "description": "This talk addresses how we tackled challenges in the Cosmos ecosystem like liquidity fragmentation, multi-chain accounts, and cross-chain contract standards, and how these solutions can be used to improve cross-chain UX in the rollup ecosystem. \r\n\r\nIf time allows, we'll also dig into designing flexible and scalable abstractions for rapid deployment of integrations (bridges, dexs, wallets) across not just many chains, but many diverse tech stacks.",
- "track": "Developer Experience",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Developper",
+ "id": "speedrun-rollups-a-beginners-guide-to-l2s-zk-and-wtf-people-are-talking-about-on-panels",
+ "sourceId": "L3Z78Q",
+ "title": "Speedrun Rollups: A Beginner's Guide to L2s, ZK, and WTF People are Talking About on Panels",
+ "description": "The L2 landscape has grown, both in terms of size, but also the development of the tech and the new problems that need to be solved.\r\n\r\nThis talk aims to take you from zero to hero, equipping you with the history, development, and current state of L2s, so you can maximize your Devcon experience without having to carry around a dictionary to understand WTF people are talking about.",
+ "track": "Layer 2",
+ "type": "Workshop",
+ "expertise": "Beginner",
+ "audience": "Hobby",
"featured": false,
"doNotRecord": false,
"keywords": [
- "DeFi",
- "Cross-chain",
- "Aggregation"
+ "ELI5"
],
"tags": [
- "Fragmentation",
- "UI/UX",
- "Account Abstraction",
- "defi",
- "cross-chain",
- "aggregation",
- "Account Abstraction",
- "Fragmentation",
- "UI/UX"
+ "Layer 2s",
+ "Scalability",
+ "ZK-EVMs",
+ "eli5",
+ "Layer 2s",
+ "Scalability",
+ "ZK-EVMs"
],
"language": "en",
"speakers": [
- "sunny-aggarwal"
+ "emily"
],
"eventId": "devcon-7",
- "slot_start": 1731577800000,
- "slot_end": 1731579600000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/10vnF2ObOK5u8Z8XcfbB0o6Q0DIS1LwGHZA_ieNhsIXg"
+ "slot_start": 1731389400000,
+ "slot_end": 1731394800000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/17fKWm64cWJz5zLVi9Av7ZypNBcbMuJYxb55zQcDbVJ8"
},
"vector": [
- 0,
- 0,
- 0,
- 6,
0,
0,
0,
@@ -690231,6 +688744,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -691015,7 +689529,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -691023,7 +689536,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -691031,7 +689543,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -691041,6 +689552,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -691114,6 +689626,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -691163,7 +689676,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -691321,6 +689833,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -691380,6 +689893,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -691447,7 +689961,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -691456,7 +689969,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -691533,11 +690045,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -691550,45 +690063,39 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "sovereignists-vs-globalists",
- "sourceId": "ZHQPKA",
- "title": "Sovereignists vs. Globalists",
- "description": "Sovereignists vs. Globalists is the real battle we should be fighting.\r\n\r\nFundamentally the goal of the space is to be Sovereign. I think very few people came into the space with the idea that well we should all rely on a single, one World government to control everything we do. But rather how do we give users a choice about what kind of systems they actually interact with on a day-to-day basis.\r\n\r\nWhat we should be thinking about when building truly decentralized truly resilient systems, is how to",
- "track": "Cypherpunk & Privacy",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Community",
- "featured": false,
+ "id": "speedrunning-chain-abstraction-eips",
+ "sourceId": "UVUPRS",
+ "title": "Speedrunning chain abstraction EIPs",
+ "description": "We look at different EIPs in pipeline across the CAKE stack and how they relate to chain abstraction.",
+ "track": "Usability",
+ "type": "Workshop",
+ "expertise": "Expert",
+ "audience": "Developer",
+ "featured": true,
"doNotRecord": false,
"keywords": [
- "Vision",
- "future",
- "resilient technologies"
+ "ChainAbstraction",
+ "CredibleAccounts",
+ "Cross-chain"
],
"tags": [
- "Decentralization Improvements",
- "Digital Sovereignty",
- "Emergency Plan",
- "resiliency",
- "technology",
- "Decentralization Improvements",
- "Digital Sovereignty",
- "Emergency Plan"
+ "cross-chain"
],
"language": "en",
"speakers": [
- "adrian-brink"
+ "ankit-chiplunkar"
],
"eventId": "devcon-7",
- "slot_start": 1731648600000,
- "slot_end": 1731649200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Ce0TClLRzVeI_KHk3Q7wjGn9iUM0mxltuQHeo2UgQuw"
+ "slot_start": 1731655200000,
+ "slot_end": 1731660600000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1up9DjzXHNhdVzKddYHp52RLJfA0EO60JAyhULDNogTk"
},
"vector": [
0,
@@ -691596,10 +690103,10 @@
0,
0,
0,
- 6,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -692194,10 +690701,11 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -692349,7 +690857,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -692393,7 +690900,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -692504,7 +691010,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -692547,7 +691052,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -692729,7 +691233,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -692816,6 +691319,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -692906,14 +691410,14 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -692926,25 +691430,43 @@
},
{
"session": {
- "id": "speed-hacking-challenge",
- "sourceId": "RSYU7K",
- "title": "Speed Hacking Challenge",
- "description": "Prize Pool: $50,000\r\n\r\nA High-Stakes Speed Hacking/ CTF Challenge\r\nAre you ready to dive headfirst into a thrilling web3 adventure? Join us for ETH Escape, a heart-pounding Speed Hacking & Capture the Flag (CTF) challenge designed to test your coding skills and problem-solving abilities on Ethereum.\r\n\r\nhttps://lu.ma/viyjky8t",
- "track": "[CLS] ETH Escape - Speed Hacking Challenge",
- "type": "Mixed Formats",
- "expertise": "",
+ "id": "sszb-a-high-performance-ssz-implementation-in-rust",
+ "sourceId": "M3SK39",
+ "title": "Sszb: A High Performance SSZ Implementation in Rust",
+ "description": "This talk goes over my EPF project for the SSZ ecosystem:\r\n\r\n- a benchmarking suite for the various rust SSZ implementations in the ecosystem to properly evaluate performance and point developers to which library they should use.\r\n- a high performance ssz implementation that's faster than existing libraries in the ecosystem",
+ "track": "[CLS] EPF Day",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "tags": [
+ "Core",
+ "Protocol"
+ ],
+ "keywords": [
+ "serialization",
+ "ssz",
+ "rust"
+ ],
+ "duration": 849,
"language": "en",
- "speakers": [],
+ "sources_swarmHash": "",
+ "sources_youtubeId": "6r2da4kl3co",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": "673480e89dbb7a90e1c6fbd5",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673480e89dbb7a90e1c6fbd5.vtt",
+ "transcript_text": " Hello, my name is Gilea. I'm here to present my work on SSEB, a high-performance SSE implementation in Rust, as well as my work on SSE Arena, a benchmarking suite for the crates in the Rust ecosystem. My motivation for working on this project was having a chance to work on optimizing an existing project, which I haven't done before. And so I learned a lot in doing this, as well as seeing what kind of gains were possible in something like SSE. It's not a real bottleneck in clients today. It's still a fairly simple task, but I was curious about what kind of losses were present over long periods of time without an optimized implementation. And so I thought this work was very appropriate for the fellowship because it's, I guess, lower priority for client teams, but still work that needs to be done. So I'm briefly going to talk about what serialization is and SSZ and go over the SSZ ecosystem as well as my work on the benchmarking suite and the implementation. Finally, talking about performance and next steps. So zooming past these first few slides, serialization is the process of transforming a data structure into a common format that the different clients can agree on which is important for consensus. Normally data structures can't be transmitted as is because of different in-memory representations and such. SSZ is the serialization scheme on Ethereum 2 meant to replace RLP on the execution layer. It has a few improvements like schemas, which are a must-have in a performance system. And Merkleization is the process in which we generate a short digest of the state while allowing for updates without rehashing the entire state. This is useful to generate small proofs of the contents inside a beacon block for light clients that don't want to hold too much state data. There are a few SSC implementations in the ecosystem, mainly in Go. Fast SSC is the most popular one and used in Geth today, although Peter also has an implementation out. In Rust specifically, there's Sigma Prime's Ethereum SSZ, Grandin's Crate, which is in public and is only used internally, and Alex Stokes' Crate, SSZRS. For the first half of the fellowship, I worked on a benchmarking suite to evaluate how these libraries perform against each other. Most of these crates have tests on consensus spec tests, but there's no real way to see how they perform on real data like beacon blocks and beacon states. So I worked on a library, well, not a library, a project called SSE Arena, which benchmarks the different crates in the ecosystem. And so it evaluates it on more controlled test cases, like lists of integers and validators, validator structs, and also evaluates it on blockchain data, like beacon blocks and beacon state, that I obtained from a beacon chain checkpoint. So I leverage Criterion for this benchmark suite which gives us handy reports, but I also use another benchmarking library called Divon which handily gives us allocation stats, so you can see how much memory is being allocated during these encoding and decoding runs. And so this gives us a robust way to measure performance. Now on to the second half of my work in the fellowship, working on my own implementation. So how does one optimize SSE? Optimizing this serialization scheme and benchmarking is kind of tricky, because most the real bottleneck or most of the optimization in encoding and decoding is simply using a more optimal data structure. There's a lot of techniques you can do to optimize this. You can lay out your data and memory so it's aligned to the word boundaries, and the other techniques like zero copy deserialization, where you can simply cast your bytes into your type. That's only really possible when you have control of the underlying data structures, which I did not have for this project. And there's a lot of reasons why you might not want to just rewrite your types with serialization in mind. Sigma Prime, in particular, has done a lot of good work with their millhouse crate, which allows for faster, sparse updates of beacon state. And so it doesn't really make sense to just change your type that create just to speed up serialization. It's better to just think about how to work with the types we have. And so being constrained by the inability to change the underlying data structure, I opted to minimize intermediate allocations. And so another second bottleneck in serialization is how much memory are you allocating in between steps to serialize and deserialize. And so here's how I went about my implementation as a ZB. It has two main differences. It uses the buff and buff mute traits. This is an abstraction over buffer types, so it encapsulates both vectors and slices, and has the added benefit of abstracting offset and counting, which greatly simplifies the implementation. So for context, you can outright define how to encode and decode certain types, but the SSEB package also provides a macro for automatically generating implementations for container types, which are like structs. And so generating this, these implementations is a hassle. We these implementations is a hassle. We provide a way to do this automatically, and the implementation for it is very simple, thanks to the buff mute traits. And second, we avoid a lot of intermediate state during the encoding process, and minimize any needed allocations during the decoding steps. This reduces the number and size of memory allocations needed to perform serialization, which is another dominant cost, as I mentioned before. Peter's Go implementation does this, and Grandeen was also another big inspiration. Although to note, Grandin only works with slices. The benefit of using buff and buff mute is being able to use vectors and any other buffer implementation you want to provide as long as you implement the trait, which not quite sure how it's gonna be used just yet, but could be handy. And it performs pretty well. So I tested this on a beacon block, decoding and encoding. It's pretty, pretty fast on the decoding part, if you'll consult the graph, I'm not quite sure how visible it is, but clocking in at around 129 microseconds on the decoding part versus 3 milliseconds in Ethereum SSC. And while the differences aren't as drastic for all types, there's similar levels of performance, around 85% encoding speedup and 95% decoding speedup on the beacon blocks. So that was for the beacon blocks. So that was for the beacon blocks. There's still some changes to be made, some fixes to be made for beacon state encoding and decoding. I know what the, there's a bug in the implementation. I know where it is. I'm gonna go fix it, but I only found it like two hours ago, so didn't really have time to fix that today. As for next steps, I want to ship a support for Merkleization and Merkle proofs with generalized indices. This is needed to have a full-fledged SSZ implementation. My focus for this fellowship was on performance of encoding and decoding. And so I left this for after the cohort. Additionally, I'd like to support a new trait I call as a Z check, which provides early input validation for, to check that an input conforms to a certain type. This would be useful if you want to reject malformed inputs earlier, instead of having a full decoding step in the hot path of your application. And then, after that, stable release. I want to gear up for, right,, stable release. I want to gear up for a stable release, adding usage docs and cleaning up anything that needs to be polished in the library. And then once that's done, I want to work on something I find interesting, but I'm not sure if other projects would want to use this. But I think it'd be cool to have support for partial encoding and decoding. For example, for large objects like beacon state, fully decoding can be very expensive. And so partial decoding would drastically speed things up, especially if you only need a subfield of your beacon state. And re-encoding and rehashing would work similarly. Again, with the Sigma Prime's millhouse implementation, they're already implementing DIR types with sparse updates in mind, and I think SSC could use Some similar ideas with regards to sparse updates I'm a little over time. I Want to thank my mentor Michael Sproul from Sigma Prime who did a most of the work I believe on Ethereum SSC. He's not a DEF CON I think. But if you're watching this, thank you. And I also want to thank Josh and Mario for providing the opportunity. I learned a lot through the cohort. And I'm glad I got the chance to do this work. Any questions? That's all for me. Alright. Any questions about the SSZ library? Not right away. Probably after a stable release. I forgot to mention also that there's no unsafe code in this. So Michael told me not to use that. Yeah. Coming soon. Yep, coming soon. All right, one more time for Gilead. Yeah. Thank you. Thank you.",
"eventId": "devcon-7",
- "slot_start": 1731551400000,
- "slot_end": 1731573000000,
+ "slot_start": 1731487500000,
+ "slot_end": 1731488400000,
"slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1TFlUSOJNbrhtdG-u3_ajWbpR--vyfBXX6KSwtcFkFI0"
+ "resources_presentation": "https://docs.google.com/presentation/d/1-4E6jtMXWSHSGuL8JFQX16HGIrgdIQ5cWNLRXq-ty9I",
+ "resources_slides": null,
+ "speakers": [
+ "ghilia-weldesselasie"
+ ]
},
"vector": [
0,
@@ -692962,10 +691484,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -693555,6 +692073,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -694003,9 +692522,8 @@
0,
0,
0,
- 0,
- 0,
- 0,
+ 2,
+ 2,
0,
0,
0,
@@ -694264,6 +692782,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -694282,37 +692801,37 @@
},
{
"session": {
- "id": "speedrun-rollups-a-beginners-guide-to-l2s-zk-and-wtf-people-are-talking-about-on-panels",
- "sourceId": "L3Z78Q",
- "title": "Speedrun Rollups: A Beginner's Guide to L2s, ZK, and WTF People are Talking About on Panels",
- "description": "The L2 landscape has grown, both in terms of size, but also the development of the tech and the new problems that need to be solved.\r\n\r\nThis talk aims to take you from zero to hero, equipping you with the history, development, and current state of L2s, so you can maximize your Devcon experience without having to carry around a dictionary to understand WTF people are talking about.",
- "track": "Layer 2",
- "type": "Workshop",
- "expertise": "Beginner",
- "audience": "Hobby",
+ "id": "stablecoin-technicalities-innovations-challenges-and-opportunities",
+ "sourceId": "XJBYKJ",
+ "title": "Stablecoin Technicalities: Innovations, Challenges, and Opportunities",
+ "description": "This session is dedicated to the evolving landscape of stablecoins, with a particular focus on the latest advancements and the role of PYUSD. This talk is tailored for developers and crypto-enthusiasts eager to explore the broader implications of stablecoin technology, integration challenges, and real-world applications of stablecoins in modern finance while focusing on PayPal's role in the Ethereum ecosystem.",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "ELI5"
+ "Stablecoins"
],
"tags": [
- "Layer 2s",
- "Scalability",
- "ZK-EVMs",
- "eli5",
- "Layer 2s",
- "Scalability",
- "ZK-EVMs"
+ "Use Cases",
+ "Remittance",
+ "Product-market fit",
+ "stablecoin",
+ "Product-market fit",
+ "Remittance",
+ "Use Cases"
],
"language": "en",
"speakers": [
- "emily"
+ "edwin-aoki"
],
"eventId": "devcon-7",
- "slot_start": 1731389400000,
- "slot_end": 1731394800000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/17fKWm64cWJz5zLVi9Av7ZypNBcbMuJYxb55zQcDbVJ8"
+ "slot_start": 1731568200000,
+ "slot_end": 1731568800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Mh_MTgJQI_Yj0brAf1A-CWrCUWCivpHPQFUodwNtN3M"
},
"vector": [
0,
@@ -694321,7 +692840,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -694921,7 +693439,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -695124,15 +693641,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -695154,6 +693662,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -695207,9 +693716,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -695415,7 +693921,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -695442,6 +693947,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -695475,7 +693981,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -695530,6 +694035,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -695630,7 +694136,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -695643,6 +694148,17 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0
@@ -695650,39 +694166,43 @@
},
{
"session": {
- "id": "speedrunning-chain-abstraction-eips",
- "sourceId": "UVUPRS",
- "title": "Speedrunning chain abstraction EIPs",
- "description": "We look at different EIPs in pipeline across the CAKE stack and how they relate to chain abstraction.",
- "track": "Usability",
- "type": "Workshop",
- "expertise": "Expert",
- "audience": "Developer",
- "featured": true,
+ "id": "staking-on-power-efficient-and-low-cost-hardware-from-arm64-to-risc-v-boards",
+ "sourceId": "J3SWYT",
+ "title": "Staking on Power Efficient and Low Cost Hardware: From ARM64 to RISC-V Boards",
+ "description": "The entry barrier to staking on Ethereum got lower, as ARM boards, the tooling and OS support have improved massively. We show the current landscape of hardware options and the software stack to go along with it. \r\nAs a glimpse into the future we will talk about RISC-V, an open CPU architecture, present the current state of RISC-V based single board computers. We will discuss the progress we have made to run Ethereum nodes on these boards and the road ahead to optimize clients.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Stakers/Validators",
+ "featured": false,
"doNotRecord": false,
"keywords": [
- "ChainAbstraction",
- "CredibleAccounts",
- "Cross-chain"
+ "node running",
+ "RISC-V",
+ "Hardware optimization"
],
"tags": [
- "cross-chain"
+ "Validator Experience",
+ "Home staking",
+ "Decentralization",
+ "optimization",
+ "hardware",
+ "Decentralization",
+ "Home staking",
+ "Validator Experience"
],
"language": "en",
"speakers": [
- "ankit-chiplunkar"
+ "aavegotch1eth",
+ "haurog"
],
"eventId": "devcon-7",
- "slot_start": 1731655200000,
- "slot_end": 1731660600000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1up9DjzXHNhdVzKddYHp52RLJfA0EO60JAyhULDNogTk"
+ "slot_start": 1731571800000,
+ "slot_end": 1731573600000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/120GkPug8WQzGtUpAMbWnOOcB7P72J5K2YG_ZVHAuEF0"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -696287,9 +694807,10 @@
0,
0,
0,
- 6,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -696469,6 +694990,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -696516,6 +695038,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -696531,6 +695054,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -696607,6 +695131,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -696775,6 +695300,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -696906,7 +695432,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -696988,6 +695513,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -696995,7 +695521,6 @@
0,
0,
0,
- 2,
0,
0,
2,
@@ -697005,51 +695530,50 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "sszb-a-high-performance-ssz-implementation-in-rust",
- "sourceId": "M3SK39",
- "title": "Sszb: A High Performance SSZ Implementation in Rust",
- "description": "This talk goes over my EPF project for the SSZ ecosystem:\r\n\r\n- a benchmarking suite for the various rust SSZ implementations in the ecosystem to properly evaluate performance and point developers to which library they should use.\r\n- a high performance ssz implementation that's faster than existing libraries in the ecosystem",
- "track": "[CLS] EPF Day",
- "type": "Talk",
+ "id": "stark-proofs-eli5",
+ "sourceId": "BKTYWY",
+ "title": "STARK proofs ELI5",
+ "description": "Let's face it, ZK proofs are intimidating. But they don't have to be!\r\nZK proofs are complex not because of the depth math they use, but because of the large number of fields of mathematics they leverage features from.\r\nIn this talk, we'll break down STARK proofs into simple blocks and colorful analogies so that you get a good high level overview of how they work",
+ "track": "Applied Cryptography",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"tags": [
- "Core",
- "Protocol"
+ "ZKP",
+ "Use cases of cryptography",
+ "STARK",
+ "eli5",
+ "STARK",
+ "Use cases of cryptography",
+ "ZKP"
],
"keywords": [
- "serialization",
- "ssz",
- "rust"
+ "ELI5"
],
- "duration": 849,
+ "duration": 496,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "6r2da4kl3co",
+ "sources_swarmHash": "69d7d8817a7c0b608f741bd14a6d7e15b142dcc69b50fdaa2c91f7cf3ff65161",
+ "sources_youtubeId": "eHPp8mFCS6E",
"sources_ipfsHash": "",
"sources_livepeerId": "",
- "sources_streamethId": "673480e89dbb7a90e1c6fbd5",
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673480e89dbb7a90e1c6fbd5.vtt",
- "transcript_text": " Hello, my name is Gilea. I'm here to present my work on SSEB, a high-performance SSE implementation in Rust, as well as my work on SSE Arena, a benchmarking suite for the crates in the Rust ecosystem. My motivation for working on this project was having a chance to work on optimizing an existing project, which I haven't done before. And so I learned a lot in doing this, as well as seeing what kind of gains were possible in something like SSE. It's not a real bottleneck in clients today. It's still a fairly simple task, but I was curious about what kind of losses were present over long periods of time without an optimized implementation. And so I thought this work was very appropriate for the fellowship because it's, I guess, lower priority for client teams, but still work that needs to be done. So I'm briefly going to talk about what serialization is and SSZ and go over the SSZ ecosystem as well as my work on the benchmarking suite and the implementation. Finally, talking about performance and next steps. So zooming past these first few slides, serialization is the process of transforming a data structure into a common format that the different clients can agree on which is important for consensus. Normally data structures can't be transmitted as is because of different in-memory representations and such. SSZ is the serialization scheme on Ethereum 2 meant to replace RLP on the execution layer. It has a few improvements like schemas, which are a must-have in a performance system. And Merkleization is the process in which we generate a short digest of the state while allowing for updates without rehashing the entire state. This is useful to generate small proofs of the contents inside a beacon block for light clients that don't want to hold too much state data. There are a few SSC implementations in the ecosystem, mainly in Go. Fast SSC is the most popular one and used in Geth today, although Peter also has an implementation out. In Rust specifically, there's Sigma Prime's Ethereum SSZ, Grandin's Crate, which is in public and is only used internally, and Alex Stokes' Crate, SSZRS. For the first half of the fellowship, I worked on a benchmarking suite to evaluate how these libraries perform against each other. Most of these crates have tests on consensus spec tests, but there's no real way to see how they perform on real data like beacon blocks and beacon states. So I worked on a library, well, not a library, a project called SSE Arena, which benchmarks the different crates in the ecosystem. And so it evaluates it on more controlled test cases, like lists of integers and validators, validator structs, and also evaluates it on blockchain data, like beacon blocks and beacon state, that I obtained from a beacon chain checkpoint. So I leverage Criterion for this benchmark suite which gives us handy reports, but I also use another benchmarking library called Divon which handily gives us allocation stats, so you can see how much memory is being allocated during these encoding and decoding runs. And so this gives us a robust way to measure performance. Now on to the second half of my work in the fellowship, working on my own implementation. So how does one optimize SSE? Optimizing this serialization scheme and benchmarking is kind of tricky, because most the real bottleneck or most of the optimization in encoding and decoding is simply using a more optimal data structure. There's a lot of techniques you can do to optimize this. You can lay out your data and memory so it's aligned to the word boundaries, and the other techniques like zero copy deserialization, where you can simply cast your bytes into your type. That's only really possible when you have control of the underlying data structures, which I did not have for this project. And there's a lot of reasons why you might not want to just rewrite your types with serialization in mind. Sigma Prime, in particular, has done a lot of good work with their millhouse crate, which allows for faster, sparse updates of beacon state. And so it doesn't really make sense to just change your type that create just to speed up serialization. It's better to just think about how to work with the types we have. And so being constrained by the inability to change the underlying data structure, I opted to minimize intermediate allocations. And so another second bottleneck in serialization is how much memory are you allocating in between steps to serialize and deserialize. And so here's how I went about my implementation as a ZB. It has two main differences. It uses the buff and buff mute traits. This is an abstraction over buffer types, so it encapsulates both vectors and slices, and has the added benefit of abstracting offset and counting, which greatly simplifies the implementation. So for context, you can outright define how to encode and decode certain types, but the SSEB package also provides a macro for automatically generating implementations for container types, which are like structs. And so generating this, these implementations is a hassle. We these implementations is a hassle. We provide a way to do this automatically, and the implementation for it is very simple, thanks to the buff mute traits. And second, we avoid a lot of intermediate state during the encoding process, and minimize any needed allocations during the decoding steps. This reduces the number and size of memory allocations needed to perform serialization, which is another dominant cost, as I mentioned before. Peter's Go implementation does this, and Grandeen was also another big inspiration. Although to note, Grandin only works with slices. The benefit of using buff and buff mute is being able to use vectors and any other buffer implementation you want to provide as long as you implement the trait, which not quite sure how it's gonna be used just yet, but could be handy. And it performs pretty well. So I tested this on a beacon block, decoding and encoding. It's pretty, pretty fast on the decoding part, if you'll consult the graph, I'm not quite sure how visible it is, but clocking in at around 129 microseconds on the decoding part versus 3 milliseconds in Ethereum SSC. And while the differences aren't as drastic for all types, there's similar levels of performance, around 85% encoding speedup and 95% decoding speedup on the beacon blocks. So that was for the beacon blocks. So that was for the beacon blocks. There's still some changes to be made, some fixes to be made for beacon state encoding and decoding. I know what the, there's a bug in the implementation. I know where it is. I'm gonna go fix it, but I only found it like two hours ago, so didn't really have time to fix that today. As for next steps, I want to ship a support for Merkleization and Merkle proofs with generalized indices. This is needed to have a full-fledged SSZ implementation. My focus for this fellowship was on performance of encoding and decoding. And so I left this for after the cohort. Additionally, I'd like to support a new trait I call as a Z check, which provides early input validation for, to check that an input conforms to a certain type. This would be useful if you want to reject malformed inputs earlier, instead of having a full decoding step in the hot path of your application. And then, after that, stable release. I want to gear up for, right,, stable release. I want to gear up for a stable release, adding usage docs and cleaning up anything that needs to be polished in the library. And then once that's done, I want to work on something I find interesting, but I'm not sure if other projects would want to use this. But I think it'd be cool to have support for partial encoding and decoding. For example, for large objects like beacon state, fully decoding can be very expensive. And so partial decoding would drastically speed things up, especially if you only need a subfield of your beacon state. And re-encoding and rehashing would work similarly. Again, with the Sigma Prime's millhouse implementation, they're already implementing DIR types with sparse updates in mind, and I think SSC could use Some similar ideas with regards to sparse updates I'm a little over time. I Want to thank my mentor Michael Sproul from Sigma Prime who did a most of the work I believe on Ethereum SSC. He's not a DEF CON I think. But if you're watching this, thank you. And I also want to thank Josh and Mario for providing the opportunity. I learned a lot through the cohort. And I'm glad I got the chance to do this work. Any questions? That's all for me. Alright. Any questions about the SSZ library? Not right away. Probably after a stable release. I forgot to mention also that there's no unsafe code in this. So Michael told me not to use that. Yeah. Coming soon. Yep, coming soon. All right, one more time for Gilead. Yeah. Thank you. Thank you.",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fea080d989c5b7b42256.vtt",
+ "transcript_text": " Everyone, welcome. My name is Henri Lutot. I work at the StarkNet Foundation where I'm the head of ecosystem. And I'm going to try to explain Stark proof like you're a five-year-old. There's many ways to explain proof. This is mine. It's not perfect, but I hope you learn something. So how I'm going to go about it is the following way. I'm going to first explain quickly what is proving, what we're trying to achieve. I'm going to talk about something that is called arithmetization. I'm going to talk about execution traces and how they get used into proofs. I'm going to talk about error correction code, and then I'm going to try to put everything together so that you have a clearer picture. So first, let's talk about proving. What is proving? Proving is a person trying to execute a computer code, and that person is called a prover, and he's trying to convince the verifier that the execution happened correctly without the verifier having to re-execute the computation. Now the kicker where this gets interesting is that there's an asymmetry between prover and verifier and it's very efficient for the verifier to verify rather than re-execute. So we save a lot on compute on the verifier side. So that's what we're trying to do. So first, now, how do we do that? We first use one step that is called arithmetization. Arithmetization, from a high level perspective, is the act of turning a computation into a set of polynomials that represent said computation. I'm not going to go too deep into that, but assume the following. When you use a computer, you know that your computer program can be turned into logic that gets executed on transistors and on zeros and ones. You can get the same result by having your computation represented as polynomials. And when you design a computer program that you want to prove, you have an expected polynomial, which is the polynomial where every execution of your program will have points falling on it. Okay? Now let's talk about an execution trace. What is an execution trace? The execution trace is the equivalent of the step-by-step log of you executing a program. If you were using a CPU, for example, it would be the register of the list of all actions, all registers, all ,, all memory steps at every single step of the execution of your program. So executing your program is the sequence of all those specific steps. Now, what do we do with this execution trace when we're trying to prove is we're turning that execution trace also into a polynomial. So you take all those data points and you turn them into points and you interpolate a polynomial that will go through this execution trace. So now you have two polynomials, right? You have the expected polynomial, the one that defines the program you're trying to prove, and you have the executed polynomial, which represents the execution you just ran. So what do we do with that? We apply something on top of it that is called error correction code. Error correction code is something that is used in telecommunication to transmit data and verify its integrity. It gives you two properties. One, you can detect error very easily. And two, you can recover from those errors. But we're not trying to recover from errors. We're trying to detect those. So we're using those techniques on those two polynomials to check if the execution polynomial is as close as possible or the closest way possible to the expected polynomial. That's how error correction code is used in StarkProve. So now wrapping it up, what we're trying to do is to convince the verifier that the execution happened over the same polynomial that the execution happened over the same polynomial that the polynomial he was expecting, which was defining the computer problem he was trying to solve. And with error correction code, we're just taking any tiny mistake that might have happened somewhere and we're amplifying it. So instead of having to check every point in the execution, the verifier can just take a few points and then check using error correction code whether there was an error somewhere. I hope that makes sense and you learned something. And here's the actual explain line 5 explanation of stark proofs. Stark proofs are five years old worst nightmare. When you're going to the swimming pool and somebody tells you, hey, if you pee, it's going to turn red and everybody will see it. Stark proofs are the exact same thing for computation. If you try to cheat at a single place, it's going to blow up everywhere and everybody will see it and will know you're a cheater and you're not going to be able to convince the verifier that you did your computation correctly. Voila, thank you. Thank you, Harry. We should probably invent something that makes your p-turns red and poor. Any questions? Ah, this one. I'll do this one. How do error-correcting codes and polynomial commitment schemes differ? I'm not entirely sure I can answer this question. I don't know enough about it, so I'm sorry. Oh, I see another hand here. This lady. By the way, thank you so much for the ELI five. I want to really understand a bit more when you say you take a few points out at the ECC stage, you take a few points and amplify it. Is that right to understand that as a statistical probability that it might have an error that you cannot detect because the sampling wasn't done to capture those points, or is that just we should feel comfortable believing that as long as it passes, it is error free? I'm not sure I understand your question, but I think what you're saying is, is there like, depending on I think what you're saying is, is there like, depending on how much samples you're taking, you have a different level of certainty. Yes, that's actually the case. When you're taking samples, you're going to see error with a probability, and the more sample you take, the lower the probability of you catching, of not catching an error. All right. Any other questions for Henry? Oh, there's one here. Hey. So do I understand properly that this verifier needs to have this execution polynomial like a like a sample that it needs to check whether it's following the same steps? Yes, it does get a form of a, it does get some sample from the execution trace. Originally in proof there are protocols so that the verifier asks the prover, hey can I get this point? Can I get this point? And then he verifies a few, but using some fancy cryptographic technique, you can actually get away with just giving, the prover can get away with giving a bunch of random points and having the verifier just use them off the bat. We take one more question. Ah, there's one there. If the prover can select the points to send to the verifier, can he select the points in such ways that the verifier won't be able to detect the error? So the fancy cryptographic technique I mentioned makes it so that he can't select points that are comfortable for him. So then he can't really cheat. Hopefully.",
"eventId": "devcon-7",
- "slot_start": 1731487500000,
- "slot_end": 1731488400000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1-4E6jtMXWSHSGuL8JFQX16HGIrgdIQ5cWNLRXq-ty9I",
+ "slot_start": 1731394200000,
+ "slot_end": 1731394800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1wuFB_JXv5HWJjXdbPmQNAk43TRxm_cDU9haSzPCxKco",
"resources_slides": null,
"speakers": [
- "ghilia-weldesselasie"
+ "henri"
]
},
"vector": [
@@ -697063,11 +695587,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -697662,11 +696181,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -697835,6 +696354,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -697881,6 +696401,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -698016,6 +696537,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -698110,8 +696632,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -698213,6 +696733,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -698388,47 +696909,53 @@
},
{
"session": {
- "id": "stablecoin-technicalities-innovations-challenges-and-opportunities",
- "sourceId": "XJBYKJ",
- "title": "Stablecoin Technicalities: Innovations, Challenges, and Opportunities",
- "description": "This session is dedicated to the evolving landscape of stablecoins, with a particular focus on the latest advancements and the role of PYUSD. This talk is tailored for developers and crypto-enthusiasts eager to explore the broader implications of stablecoin technology, integration challenges, and real-world applications of stablecoins in modern finance while focusing on PayPal's role in the Ethereum ecosystem.",
- "track": "Real World Ethereum",
+ "id": "start-contributing-to-economic-protocol-development",
+ "sourceId": "CEZPBS",
+ "title": "Start contributing to economic protocol development",
+ "description": "Protocol development needs more economists, yet many potential contributors do not know which problems are important to Ethereum protocol development. This talk bridges the gap for those interested in blockchain research who want to work on impactful problems. The talk will overview different economic research areas at the protocol level. Examples include an economic perspective on consensus systems, transaction fee mechanism design, and economic sides of current EIPs.",
+ "track": "Cryptoeconomics",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Stablecoins"
- ],
"tags": [
- "Use Cases",
- "Remittance",
- "Product-market fit",
- "stablecoin",
- "Product-market fit",
- "Remittance",
- "Use Cases"
+ "Core Protocol",
+ "Economics",
+ "introduction",
+ "Core Protocol",
+ "Economics"
],
- "language": "en",
- "speakers": [
- "edwin-aoki"
+ "keywords": [
+ "Introduction"
],
+ "duration": 423,
+ "language": "en",
+ "sources_swarmHash": "6341c1973358b364e4a0b42f702c81d66a466e72787bc14c72216143e19bfb17",
+ "sources_youtubeId": "CaauVb5jcH8",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731568200000,
- "slot_end": 1731568800000,
+ "slot_start": 1731484800000,
+ "slot_end": 1731485400000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Mh_MTgJQI_Yj0brAf1A-CWrCUWCivpHPQFUodwNtN3M"
+ "resources_presentation": "https://docs.google.com/presentation/d/1oT8-qF_kFLzRfy9StlucF5G7CCSCbwTrU3VGnmV4M-M",
+ "resources_slides": null,
+ "speakers": [
+ "julian-ma"
+ ]
},
"vector": [
0,
0,
+ 6,
0,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -699190,6 +697717,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -699204,6 +697733,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -699231,7 +697761,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -699252,7 +697781,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -699538,7 +698066,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -699628,7 +698155,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -699654,6 +698180,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -699737,7 +698264,6 @@
2,
0,
0,
- 0,
2,
0,
0,
@@ -699750,47 +698276,43 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "staking-on-power-efficient-and-low-cost-hardware-from-arm64-to-risc-v-boards",
- "sourceId": "J3SWYT",
- "title": "Staking on Power Efficient and Low Cost Hardware: From ARM64 to RISC-V Boards",
- "description": "The entry barrier to staking on Ethereum got lower, as ARM boards, the tooling and OS support have improved massively. We show the current landscape of hardware options and the software stack to go along with it. \r\nAs a glimpse into the future we will talk about RISC-V, an open CPU architecture, present the current state of RISC-V based single board computers. We will discuss the progress we have made to run Ethereum nodes on these boards and the road ahead to optimize clients.",
+ "id": "state-contention-rules-everything-around-me",
+ "sourceId": "XGHU89",
+ "title": "State Contention Rules Everything Around Me",
+ "description": "State contention causes MEV, prevents parallelization, breaks gas simulation, causes transactions to revert, etc. etc. We'll discuss state contention in practical and theoretical systems (e.g. OS threads and type systems) and how/why synchronization primitives developed. We'll cover why state is contentious, what state is contentious, what can be accomplished by making state non-contentitious, and strategies for refactoring existing systems to reduce contention.",
"track": "Core Protocol",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Stakers/Validators",
+ "expertise": "Expert",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "node running",
- "RISC-V",
- "Hardware optimization"
+ "Synchronization",
+ "Concurrency"
],
"tags": [
- "Validator Experience",
- "Home staking",
- "Decentralization",
- "optimization",
- "hardware",
- "Decentralization",
- "Home staking",
- "Validator Experience"
+ "Layer 1",
+ "Architecture",
+ "Cross-L2",
+ "concurrency",
+ "Architecture",
+ "Cross-L2",
+ "Layer 1"
],
"language": "en",
"speakers": [
- "aavegotch1eth",
- "haurog"
+ "james-prestwich"
],
"eventId": "devcon-7",
- "slot_start": 1731571800000,
- "slot_end": 1731573600000,
+ "slot_start": 1731579000000,
+ "slot_end": 1731580800000,
"slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/120GkPug8WQzGtUpAMbWnOOcB7P72J5K2YG_ZVHAuEF0"
+ "resources_presentation": "https://docs.google.com/presentation/d/1cS2GTJFjotanBsdxY8DrP-qcMwV7ijAs3-hVV-oIS40"
},
"vector": [
0,
@@ -700403,8 +698925,6 @@
0,
0,
0,
- 0,
- 6,
6,
0,
0,
@@ -700559,6 +699079,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -700583,7 +699104,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -700606,6 +699126,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -700631,7 +699153,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -700647,7 +699168,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -700694,6 +699214,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -700724,7 +699245,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -700744,6 +699264,9 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
0,
0,
0,
@@ -700894,7 +699417,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -701107,6 +699629,7 @@
0,
0,
2,
+ 2,
0,
0,
0,
@@ -701116,10 +699639,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -701128,46 +699647,34 @@
},
{
"session": {
- "id": "stark-proofs-eli5",
- "sourceId": "BKTYWY",
- "title": "STARK proofs ELI5",
- "description": "Let's face it, ZK proofs are intimidating. But they don't have to be!\r\nZK proofs are complex not because of the depth math they use, but because of the large number of fields of mathematics they leverage features from.\r\nIn this talk, we'll break down STARK proofs into simple blocks and colorful analogies so that you get a good high level overview of how they work",
- "track": "Applied Cryptography",
+ "id": "state-minimized-layer-2s-and-why-ethereum-greater-evm",
+ "sourceId": "VDFBMT",
+ "title": "State Minimized Layer-2s and Why Ethereum > EVM",
+ "description": "Ethereum is at a critical juncture in its development. Many layer-2s are of the same mentality of copy and pasting their architecture and have not innovated over key blockchain problems such as parallel execution or state growth. If Ethereum is to compete with other alternative high performance blockchains, it has to solve for state growth. This talk will explore the landscape of state minimized layer-2s and show how Ethereum will be able to go beyond the state problem with non-EVM based design.",
+ "track": "Layer 2",
"type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "ZKP",
- "Use cases of cryptography",
- "STARK",
- "eli5",
- "STARK",
- "Use cases of cryptography",
- "ZKP"
- ],
"keywords": [
- "ELI5"
+ "node-requirements"
+ ],
+ "tags": [
+ "Network State",
+ "node-requirements",
+ "Network",
+ "State"
],
- "duration": 496,
"language": "en",
- "sources_swarmHash": "69d7d8817a7c0b608f741bd14a6d7e15b142dcc69b50fdaa2c91f7cf3ff65161",
- "sources_youtubeId": "eHPp8mFCS6E",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732fea080d989c5b7b42256.vtt",
- "transcript_text": " Everyone, welcome. My name is Henri Lutot. I work at the StarkNet Foundation where I'm the head of ecosystem. And I'm going to try to explain Stark proof like you're a five-year-old. There's many ways to explain proof. This is mine. It's not perfect, but I hope you learn something. So how I'm going to go about it is the following way. I'm going to first explain quickly what is proving, what we're trying to achieve. I'm going to talk about something that is called arithmetization. I'm going to talk about execution traces and how they get used into proofs. I'm going to talk about error correction code, and then I'm going to try to put everything together so that you have a clearer picture. So first, let's talk about proving. What is proving? Proving is a person trying to execute a computer code, and that person is called a prover, and he's trying to convince the verifier that the execution happened correctly without the verifier having to re-execute the computation. Now the kicker where this gets interesting is that there's an asymmetry between prover and verifier and it's very efficient for the verifier to verify rather than re-execute. So we save a lot on compute on the verifier side. So that's what we're trying to do. So first, now, how do we do that? We first use one step that is called arithmetization. Arithmetization, from a high level perspective, is the act of turning a computation into a set of polynomials that represent said computation. I'm not going to go too deep into that, but assume the following. When you use a computer, you know that your computer program can be turned into logic that gets executed on transistors and on zeros and ones. You can get the same result by having your computation represented as polynomials. And when you design a computer program that you want to prove, you have an expected polynomial, which is the polynomial where every execution of your program will have points falling on it. Okay? Now let's talk about an execution trace. What is an execution trace? The execution trace is the equivalent of the step-by-step log of you executing a program. If you were using a CPU, for example, it would be the register of the list of all actions, all registers, all ,, all memory steps at every single step of the execution of your program. So executing your program is the sequence of all those specific steps. Now, what do we do with this execution trace when we're trying to prove is we're turning that execution trace also into a polynomial. So you take all those data points and you turn them into points and you interpolate a polynomial that will go through this execution trace. So now you have two polynomials, right? You have the expected polynomial, the one that defines the program you're trying to prove, and you have the executed polynomial, which represents the execution you just ran. So what do we do with that? We apply something on top of it that is called error correction code. Error correction code is something that is used in telecommunication to transmit data and verify its integrity. It gives you two properties. One, you can detect error very easily. And two, you can recover from those errors. But we're not trying to recover from errors. We're trying to detect those. So we're using those techniques on those two polynomials to check if the execution polynomial is as close as possible or the closest way possible to the expected polynomial. That's how error correction code is used in StarkProve. So now wrapping it up, what we're trying to do is to convince the verifier that the execution happened over the same polynomial that the execution happened over the same polynomial that the polynomial he was expecting, which was defining the computer problem he was trying to solve. And with error correction code, we're just taking any tiny mistake that might have happened somewhere and we're amplifying it. So instead of having to check every point in the execution, the verifier can just take a few points and then check using error correction code whether there was an error somewhere. I hope that makes sense and you learned something. And here's the actual explain line 5 explanation of stark proofs. Stark proofs are five years old worst nightmare. When you're going to the swimming pool and somebody tells you, hey, if you pee, it's going to turn red and everybody will see it. Stark proofs are the exact same thing for computation. If you try to cheat at a single place, it's going to blow up everywhere and everybody will see it and will know you're a cheater and you're not going to be able to convince the verifier that you did your computation correctly. Voila, thank you. Thank you, Harry. We should probably invent something that makes your p-turns red and poor. Any questions? Ah, this one. I'll do this one. How do error-correcting codes and polynomial commitment schemes differ? I'm not entirely sure I can answer this question. I don't know enough about it, so I'm sorry. Oh, I see another hand here. This lady. By the way, thank you so much for the ELI five. I want to really understand a bit more when you say you take a few points out at the ECC stage, you take a few points and amplify it. Is that right to understand that as a statistical probability that it might have an error that you cannot detect because the sampling wasn't done to capture those points, or is that just we should feel comfortable believing that as long as it passes, it is error free? I'm not sure I understand your question, but I think what you're saying is, is there like, depending on I think what you're saying is, is there like, depending on how much samples you're taking, you have a different level of certainty. Yes, that's actually the case. When you're taking samples, you're going to see error with a probability, and the more sample you take, the lower the probability of you catching, of not catching an error. All right. Any other questions for Henry? Oh, there's one here. Hey. So do I understand properly that this verifier needs to have this execution polynomial like a like a sample that it needs to check whether it's following the same steps? Yes, it does get a form of a, it does get some sample from the execution trace. Originally in proof there are protocols so that the verifier asks the prover, hey can I get this point? Can I get this point? And then he verifies a few, but using some fancy cryptographic technique, you can actually get away with just giving, the prover can get away with giving a bunch of random points and having the verifier just use them off the bat. We take one more question. Ah, there's one there. If the prover can select the points to send to the verifier, can he select the points in such ways that the verifier won't be able to detect the error? So the fancy cryptographic technique I mentioned makes it so that he can't select points that are comfortable for him. So then he can't really cheat. Hopefully.",
- "eventId": "devcon-7",
- "slot_start": 1731394200000,
- "slot_end": 1731394800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1wuFB_JXv5HWJjXdbPmQNAk43TRxm_cDU9haSzPCxKco",
- "resources_slides": null,
"speakers": [
- "henri"
- ]
+ "nick-dodson"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731582600000,
+ "slot_end": 1731583200000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1UJnCtYTecznVLrleCgEgafIef7JIuF9xeJmVPJ4TRHM"
},
"vector": [
0,
@@ -701177,9 +699684,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -701783,8 +700287,8 @@
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -701950,7 +700454,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -701970,6 +700473,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -701997,7 +700501,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -702133,7 +700636,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -702330,7 +700832,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -702408,6 +700909,9 @@
0,
0,
0,
+ 2,
+ 2,
+ 2,
0,
0,
0,
@@ -702505,55 +701009,46 @@
},
{
"session": {
- "id": "start-contributing-to-economic-protocol-development",
- "sourceId": "CEZPBS",
- "title": "Start contributing to economic protocol development",
- "description": "Protocol development needs more economists, yet many potential contributors do not know which problems are important to Ethereum protocol development. This talk bridges the gap for those interested in blockchain research who want to work on impactful problems. The talk will overview different economic research areas at the protocol level. Examples include an economic perspective on consensus systems, transaction fee mechanism design, and economic sides of current EIPs.",
- "track": "Cryptoeconomics",
- "type": "Lightning Talk",
+ "id": "state-of-the-ens",
+ "sourceId": "VBSW3N",
+ "title": "State of the ENS",
+ "description": "Jeff Lau, co-founder of ENS, gives an update on the state of ENS, and our progress with migrating over to layer 2. ENS's approach to layer 2 aims to preserve users' ability to choose where their names are stored and administered, while massively reducing transaction costs and increasing scalability for the vast majority of users. Embracing its status as a public good, we want to make ENS the most useful to the largest number of people possible.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
"expertise": "Beginner",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Core Protocol",
- "Economics",
- "introduction",
- "Core Protocol",
- "Economics"
- ],
"keywords": [
- "Introduction"
+ "Usability"
+ ],
+ "tags": [
+ "Protocol Design",
+ "Identity",
+ "Public good",
+ "usability",
+ "Identity",
+ "Protocol Design",
+ "Public good"
],
- "duration": 423,
"language": "en",
- "sources_swarmHash": "6341c1973358b364e4a0b42f702c81d66a466e72787bc14c72216143e19bfb17",
- "sources_youtubeId": "CaauVb5jcH8",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731484800000,
- "slot_end": 1731485400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1oT8-qF_kFLzRfy9StlucF5G7CCSCbwTrU3VGnmV4M-M",
- "resources_slides": null,
"speakers": [
- "julian-ma"
- ]
+ "jeff-lau"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731638700000,
+ "slot_end": 1731640500000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1z_YHSVofOJSq48tqbAiqN423gAZrzi5rzZMND8BcHDw"
},
"vector": [
- 0,
- 0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -703316,7 +701811,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -703332,8 +701826,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -703345,8 +701837,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -703406,6 +701900,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -703859,10 +702354,8 @@
0,
0,
0,
- 0,
2,
0,
- 0,
2,
0,
0,
@@ -703875,55 +702368,43 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "state-contention-rules-everything-around-me",
- "sourceId": "XGHU89",
- "title": "State Contention Rules Everything Around Me",
- "description": "State contention causes MEV, prevents parallelization, breaks gas simulation, causes transactions to revert, etc. etc. We'll discuss state contention in practical and theoretical systems (e.g. OS threads and type systems) and how/why synchronization primitives developed. We'll cover why state is contentious, what state is contentious, what can be accomplished by making state non-contentitious, and strategies for refactoring existing systems to reduce contention.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Expert",
+ "id": "stress-escape-relaxing-aromatic-oils-and-singing-gongs-and-bowls",
+ "sourceId": "KVDNNN",
+ "title": "Stress Escape (Relaxing Aromatic Oils and Singing Gongs and Bowls)",
+ "description": "By master Ice \r\n- Let go of stress with the calming sounds of gongs and bowls\r\n- Enhance by soothing essential oil scents. You’ll also receive a take-home essential oil roller to keep the relaxation going after the session.\r\n\r\nNov 15 13:00 - 13:45",
+ "track": "Entertainment",
+ "type": "Mixed Formats",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Synchronization",
- "Concurrency"
- ],
- "tags": [
- "Layer 1",
- "Architecture",
- "Cross-L2",
- "concurrency",
- "Architecture",
- "Cross-L2",
- "Layer 1"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "james-prestwich"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731579000000,
- "slot_end": 1731580800000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1cS2GTJFjotanBsdxY8DrP-qcMwV7ijAs3-hVV-oIS40"
+ "slot_start": 1731650400000,
+ "slot_end": 1731653100000,
+ "slot_roomId": "decompression-room",
+ "resources_presentation": "https://docs.google.com/presentation/d/1yzroGPmzEN55RgegoRuiSo7Qe_-eunH6UGPIczkFag0"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -704529,7 +703010,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -704681,7 +703161,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -704728,7 +703207,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -704816,7 +703294,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -704866,7 +703343,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -705231,6 +703707,8 @@
0,
0,
2,
+ 0,
+ 0,
2,
0,
0,
@@ -705249,34 +703727,39 @@
},
{
"session": {
- "id": "state-minimized-layer-2s-and-why-ethereum-greater-evm",
- "sourceId": "VDFBMT",
- "title": "State Minimized Layer-2s and Why Ethereum > EVM",
- "description": "Ethereum is at a critical juncture in its development. Many layer-2s are of the same mentality of copy and pasting their architecture and have not innovated over key blockchain problems such as parallel execution or state growth. If Ethereum is to compete with other alternative high performance blockchains, it has to solve for state growth. This talk will explore the landscape of state minimized layer-2s and show how Ethereum will be able to go beyond the state problem with non-EVM based design.",
- "track": "Layer 2",
- "type": "Lightning Talk",
+ "id": "structuring-censorship-resistant-privacy-protocols-risks-and-considerations",
+ "sourceId": "MVJFDX",
+ "title": "Structuring Censorship Resistant Privacy Protocols: Risks and Considerations",
+ "description": "This workshop is aimed at developers, legal professionals, and project managers involved in the creation and maintenance of privacy-focused projects and will guide participants through the various considerations and risks that need to be managed during the structuring, development and launch of these protocols.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Product",
"featured": false,
- "doNotRecord": false,
+ "doNotRecord": true,
"keywords": [
- "node-requirements"
+ "Legal"
],
"tags": [
- "Network State",
- "node-requirements",
- "Network",
- "State"
+ "Frameworks",
+ "Privacy",
+ "Censorship Resistance",
+ "legal",
+ "Censorship Resistance",
+ "Frameworks",
+ "Privacy"
],
"language": "en",
"speakers": [
- "nick-dodson"
+ "fatemeh-fannizadeh",
+ "andre-omietanski",
+ "amal-ibraymi"
],
"eventId": "devcon-7",
- "slot_start": 1731582600000,
- "slot_end": 1731583200000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1UJnCtYTecznVLrleCgEgafIef7JIuF9xeJmVPJ4TRHM"
+ "slot_start": 1731576600000,
+ "slot_end": 1731582000000,
+ "slot_roomId": "classroom-d",
+ "resources_presentation": "https://docs.google.com/presentation/d/1hNJE0EKTqY7KkSQmnZdpNsxrFfsKPlhwl0VFWn9f3pA"
},
"vector": [
0,
@@ -705284,9 +703767,9 @@
0,
0,
0,
+ 6,
0,
0,
- 6,
0,
0,
0,
@@ -705804,6 +704287,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -705891,11 +704375,19 @@
0,
0,
0,
+ 6,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -706078,7 +704570,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -706125,6 +704616,18 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
0,
0,
0,
@@ -706156,6 +704659,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -706493,6 +704998,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -706517,33 +705024,6 @@
0,
0,
0,
- 2,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -706596,11 +705076,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -706614,43 +705094,40 @@
},
{
"session": {
- "id": "state-of-the-ens",
- "sourceId": "VBSW3N",
- "title": "State of the ENS",
- "description": "Jeff Lau, co-founder of ENS, gives an update on the state of ENS, and our progress with migrating over to layer 2. ENS's approach to layer 2 aims to preserve users' ability to choose where their names are stored and administered, while massively reducing transaction costs and increasing scalability for the vast majority of users. Embracing its status as a public good, we want to make ENS the most useful to the largest number of people possible.",
- "track": "Real World Ethereum",
+ "id": "superliquid-mechanisms-for-decentralized-stablecoins",
+ "sourceId": "SLNQ8K",
+ "title": "Superliquid Mechanisms for Decentralized Stablecoins",
+ "description": "USDC and USDT outpace decentralized stablecoins in large part due to their liquidity. This talk covers the theory, data, and risks of stablecoin liquidity innovations. This will include mint/redemption mechanism design, liquidity pool design, rehypothecation, and protocol-owned liquidity. The analysis will distill how the flexibility of decentralized stablecoin issuance mechanisms can safely be used to their advantage over centralized stablecoins, which Gyroscope v2 is putting into practice.",
+ "track": "Cryptoeconomics",
"type": "Talk",
- "expertise": "Beginner",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Usability"
+ "Stablecoins",
+ "DeFi"
],
"tags": [
- "Protocol Design",
- "Identity",
- "Public good",
- "usability",
- "Identity",
- "Protocol Design",
- "Public good"
+ "Mechanism design",
+ "Economics",
+ "AMMs",
+ "defi",
+ "AMMs",
+ "Economics",
+ "Mechanism design"
],
"language": "en",
"speakers": [
- "jeff-lau"
+ "ariah-klages-mundt"
],
"eventId": "devcon-7",
- "slot_start": 1731638700000,
- "slot_end": 1731640500000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1z_YHSVofOJSq48tqbAiqN423gAZrzi5rzZMND8BcHDw"
+ "slot_start": 1731641400000,
+ "slot_end": 1731643200000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Uq2Z7r9A4ctbRuT4PbYzFJRFe2xqpvo_AnrVxHcMjiU"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
0,
0,
6,
@@ -707135,6 +705612,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -707264,8 +705742,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -707408,6 +705884,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -707435,6 +705912,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -707445,10 +705923,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -707484,6 +705960,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -707508,7 +705985,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -707592,6 +706068,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -707888,7 +706365,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -707964,6 +706440,8 @@
0,
2,
0,
+ 0,
+ 0,
2,
0,
0,
@@ -707982,32 +706460,53 @@
},
{
"session": {
- "id": "stress-escape-relaxing-aromatic-oils-and-singing-gongs-and-bowls",
- "sourceId": "KVDNNN",
- "title": "Stress Escape (Relaxing Aromatic Oils and Singing Gongs and Bowls)",
- "description": "By master Ice \r\n- Let go of stress with the calming sounds of gongs and bowls\r\n- Enhance by soothing essential oil scents. You’ll also receive a take-home essential oil roller to keep the relaxation going after the session.\r\n\r\nNov 15 13:00 - 13:45",
- "track": "Entertainment",
- "type": "Mixed Formats",
- "expertise": "",
+ "id": "supernodes-on-a-shoestring-democratizing-ethereum-with-low-power-hardware",
+ "sourceId": "W3DKPQ",
+ "title": "Supernodes on a Shoestring: Democratizing Ethereum with Low-Power Hardware",
+ "description": "Learn to run a full Ethereum supernode (L1 & L2) on affordable hardware (ARM devices) This live demo will guide you through selecting the hardware, installing EoA image who automatically install and configure all the software. Become a part of the decentralized Ethereum on a easy and power efficient way.",
+ "track": "Core Protocol",
+ "type": "Workshop",
+ "expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "tags": [
+ "Layer 1",
+ "Decentralization Improvements",
+ "Layer 2s",
+ "Decentralization",
+ "hardware",
+ "low-power",
+ "Decentralization",
+ "Decentralization Improvements",
+ "Layer 1",
+ "Layer 2s"
+ ],
+ "keywords": [
+ "Node Operation",
+ "Low-Power Hardware"
+ ],
+ "duration": 4662,
"language": "en",
- "speakers": [],
+ "sources_swarmHash": "46fe2d92049008021f297bb1ee93996f8d721813789639773fef05ea0c778d9a",
+ "sources_youtubeId": "k2lYtOi1KJY",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731650400000,
- "slot_end": 1731653100000,
- "slot_roomId": "decompression-room",
- "resources_presentation": "https://docs.google.com/presentation/d/1yzroGPmzEN55RgegoRuiSo7Qe_-eunH6UGPIczkFag0"
+ "slot_start": 1731472200000,
+ "slot_end": 1731477600000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/1iW-qq2w5XkPf2rNpSWzKfErwV_ysrpVcA97rrOKKEyQ",
+ "resources_slides": null,
+ "speakers": [
+ "diego-losada",
+ "fernando-collado"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -708301,6 +706800,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -708622,6 +707122,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -708761,6 +707262,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -708769,6 +707271,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -708819,6 +707322,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -708854,6 +707358,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -708930,6 +707435,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -709238,11 +707744,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -709319,7 +707821,6 @@
0,
2,
0,
- 0,
2,
0,
0,
@@ -709338,47 +707839,56 @@
},
{
"session": {
- "id": "structuring-censorship-resistant-privacy-protocols-risks-and-considerations",
- "sourceId": "MVJFDX",
- "title": "Structuring Censorship Resistant Privacy Protocols: Risks and Considerations",
- "description": "This workshop is aimed at developers, legal professionals, and project managers involved in the creation and maintenance of privacy-focused projects and will guide participants through the various considerations and risks that need to be managed during the structuring, development and launch of these protocols.",
- "track": "Cypherpunk & Privacy",
- "type": "Workshop",
+ "id": "sybil-proof-mechanisms",
+ "sourceId": "7QENZH",
+ "title": "Sybil-Proof Mechanisms",
+ "description": "I discuss a fundamental impossibility result on proposer selection mechanisms: If different actors can generate different value from block proposal (or sequencing) rights, the only sybil-proof and incentive compatible way of assigning proposal rights is through an (arguably centralizing) auction. In other words, any proposer selection mechanism can at most satisfy two out of three fundamental requirements: incentive compatibility, sybil-resistance and decentralization.",
+ "track": "Cryptoeconomics",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Product",
+ "audience": "Research",
"featured": false,
- "doNotRecord": true,
- "keywords": [
- "Legal"
- ],
+ "doNotRecord": false,
"tags": [
- "Frameworks",
- "Privacy",
- "Censorship Resistance",
- "legal",
- "Censorship Resistance",
- "Frameworks",
- "Privacy"
+ "PBS",
+ "Mechanism design",
+ "Game Theory",
+ "MEV",
+ "apps",
+ "Game Theory",
+ "Mechanism design",
+ "MEV",
+ "PBS"
],
- "language": "en",
- "speakers": [
- "fatemeh-fannizadeh",
- "andre-omietanski",
- "amal-ibraymi"
+ "keywords": [
+ "APS"
],
+ "duration": 534,
+ "language": "en",
+ "sources_swarmHash": "128d8549b9f6be7505306f18e50a994b8b3afbd30a997bae8bf236e23af9240c",
+ "sources_youtubeId": "ifMRDZvV2kU",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673468089dbb7a90e18442a0.vtt",
+ "transcript_text": " All right, here we go. I wanted to pitch my favorite theorem of 2024 in mechanism design, very subjective. That's joint work with our brilliant intern and flashbots Minghao and Akaki over there. and I want to also tell you a bit about how it relates to Ethereum roadmap stuff like PBS and so on. So here's a question have you ever wondered can we have a decentralized builder market under any mechanism that we can use to select a proposer or builder And how can we make this question more precise? How can we think about it from first principles? And we wanted to turn it into a mechanism design questions. So we are wondering, okay, could we have an allocation mechanism to select a proposer that proposes blocks? And we operate in a permissionless system, so we worry a lot about symbols, right?",
"eventId": "devcon-7",
- "slot_start": 1731576600000,
- "slot_end": 1731582000000,
- "slot_roomId": "classroom-d",
- "resources_presentation": "https://docs.google.com/presentation/d/1hNJE0EKTqY7KkSQmnZdpNsxrFfsKPlhwl0VFWn9f3pA"
+ "slot_start": 1731486600000,
+ "slot_end": 1731487200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1zjLtbzOM-9p0FmUus6R7GhQq9rHDQj5paePedPnL_rA",
+ "resources_slides": null,
+ "speakers": [
+ "christoph-schlegel"
+ ]
},
"vector": [
0,
0,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -709567,6 +708077,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -709903,7 +708414,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -709991,8 +708501,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -710126,10 +708634,13 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -710160,6 +708671,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -710230,7 +708749,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -710241,7 +708759,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -710273,7 +708790,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -710605,6 +709121,22 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -710615,31 +709147,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -710691,10 +709198,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -710708,43 +709215,29 @@
},
{
"session": {
- "id": "superliquid-mechanisms-for-decentralized-stablecoins",
- "sourceId": "SLNQ8K",
- "title": "Superliquid Mechanisms for Decentralized Stablecoins",
- "description": "USDC and USDT outpace decentralized stablecoins in large part due to their liquidity. This talk covers the theory, data, and risks of stablecoin liquidity innovations. This will include mint/redemption mechanism design, liquidity pool design, rehypothecation, and protocol-owned liquidity. The analysis will distill how the flexibility of decentralized stablecoin issuance mechanisms can safely be used to their advantage over centralized stablecoins, which Gyroscope v2 is putting into practice.",
- "track": "Cryptoeconomics",
- "type": "Talk",
- "expertise": "Intermediate",
+ "id": "synthetic-melodies-a-digital-soundscape",
+ "sourceId": "EZ3EVX",
+ "title": "Synthetic Melodies: A Digital Soundscape",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience! Dive into the bleeps and bloops curated by RBRD, weaving together experimental, ambient and IDM. Let’s connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Stablecoins",
- "DeFi"
- ],
- "tags": [
- "Mechanism design",
- "Economics",
- "AMMs",
- "defi",
- "AMMs",
- "Economics",
- "Mechanism design"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "ariah-klages-mundt"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731641400000,
- "slot_end": 1731643200000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1Uq2Z7r9A4ctbRuT4PbYzFJRFe2xqpvo_AnrVxHcMjiU"
+ "slot_start": 1731402000000,
+ "slot_end": 1731405600000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1kQVFXulZrmOXmwN9TZ75ma4CYWlC0Kv9WxWB6w0qyAg"
},
"vector": [
0,
0,
- 6,
0,
0,
0,
@@ -710752,6 +709245,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -711230,7 +709725,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -711501,7 +709995,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -711529,7 +710022,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -711577,7 +710069,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -711685,7 +710176,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -712055,9 +710545,10 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
+ 0,
0,
2,
0,
@@ -712077,63 +710568,41 @@
},
{
"session": {
- "id": "supernodes-on-a-shoestring-democratizing-ethereum-with-low-power-hardware",
- "sourceId": "W3DKPQ",
- "title": "Supernodes on a Shoestring: Democratizing Ethereum with Low-Power Hardware",
- "description": "Learn to run a full Ethereum supernode (L1 & L2) on affordable hardware (ARM devices) This live demo will guide you through selecting the hardware, installing EoA image who automatically install and configure all the software. Become a part of the decentralized Ethereum on a easy and power efficient way.",
- "track": "Core Protocol",
- "type": "Workshop",
- "expertise": "Beginner",
+ "id": "synto-nikka",
+ "sourceId": "ZBSJDY",
+ "title": "Synto Nikka",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Layer 1",
- "Decentralization Improvements",
- "Layer 2s",
- "Decentralization",
- "hardware",
- "low-power",
- "Decentralization",
- "Decentralization Improvements",
- "Layer 1",
- "Layer 2s"
- ],
- "keywords": [
- "Node Operation",
- "Low-Power Hardware"
- ],
- "duration": 4662,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "46fe2d92049008021f297bb1ee93996f8d721813789639773fef05ea0c778d9a",
- "sources_youtubeId": "k2lYtOi1KJY",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731472200000,
- "slot_end": 1731477600000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/1iW-qq2w5XkPf2rNpSWzKfErwV_ysrpVcA97rrOKKEyQ",
- "resources_slides": null,
- "speakers": [
- "diego-losada",
- "fernando-collado"
- ]
+ "slot_start": 1731492000000,
+ "slot_end": 1731497400000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1qlDffU55LOyqC5g5m_XelYjXsBTWIYahAHtzcqgHwic"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -712418,7 +710887,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -712744,7 +711212,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -712882,7 +711349,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -712891,7 +711357,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -712942,7 +711407,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -712978,7 +711442,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -713055,7 +711518,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -713367,7 +711829,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -713441,6 +711902,7 @@
0,
2,
0,
+ 0,
2,
0,
0,
@@ -713459,50 +711921,46 @@
},
{
"session": {
- "id": "sybil-proof-mechanisms",
- "sourceId": "7QENZH",
- "title": "Sybil-Proof Mechanisms",
- "description": "I discuss a fundamental impossibility result on proposer selection mechanisms: If different actors can generate different value from block proposal (or sequencing) rights, the only sybil-proof and incentive compatible way of assigning proposal rights is through an (arguably centralizing) auction. In other words, any proposer selection mechanism can at most satisfy two out of three fundamental requirements: incentive compatibility, sybil-resistance and decentralization.",
- "track": "Cryptoeconomics",
+ "id": "tackling-east-asias-population-decline-issues-with-local-coops-subsystem-for-local-governance",
+ "sourceId": "QKMVPC",
+ "title": "Tackling East Asia's Population Decline Issues with Local Coop's Subsystem for Local Governance",
+ "description": "Local Coop envisions a world beyond nation-states and capitalism, fostering mutual aid and co-creation. It promotes self-reliant community autonomy and public goods, targeting East Asia's declining population. The system includes digital resident IDs with NFTs, democratizes emissions trading, and manages resources sustainably. Partnerships with local governments facilitate transferring public goods and services to Local Coop, optimized through technology and resident participation.",
+ "track": "Real World Ethereum",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "expertise": "Beginner",
+ "audience": "Local/SEA",
"featured": false,
"doNotRecord": false,
- "tags": [
- "PBS",
- "Mechanism design",
- "Game Theory",
- "MEV",
- "apps",
- "Game Theory",
- "Mechanism design",
- "MEV",
- "PBS"
- ],
"keywords": [
- "APS"
+ "Population Decline",
+ "Local Government",
+ "NFT",
+ "Public Service"
+ ],
+ "tags": [
+ "Public good",
+ "Local Impact",
+ "service",
+ "public",
+ "Autonomous World",
+ "Local Impact",
+ "Public good"
],
- "duration": 534,
"language": "en",
- "sources_swarmHash": "128d8549b9f6be7505306f18e50a994b8b3afbd30a997bae8bf236e23af9240c",
- "sources_youtubeId": "ifMRDZvV2kU",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673468089dbb7a90e18442a0.vtt",
- "transcript_text": " All right, here we go. I wanted to pitch my favorite theorem of 2024 in mechanism design, very subjective. That's joint work with our brilliant intern and flashbots Minghao and Akaki over there. and I want to also tell you a bit about how it relates to Ethereum roadmap stuff like PBS and so on. So here's a question have you ever wondered can we have a decentralized builder market under any mechanism that we can use to select a proposer or builder And how can we make this question more precise? How can we think about it from first principles? And we wanted to turn it into a mechanism design questions. So we are wondering, okay, could we have an allocation mechanism to select a proposer that proposes blocks? And we operate in a permissionless system, so we worry a lot about symbols, right?",
+ "speakers": [
+ "atsushi-hayashiatsu"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731486600000,
- "slot_end": 1731487200000,
+ "slot_start": 1731573600000,
+ "slot_end": 1731574200000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1zjLtbzOM-9p0FmUus6R7GhQq9rHDQj5paePedPnL_rA",
- "resources_slides": null,
- "speakers": [
- "christoph-schlegel"
- ]
+ "resources_presentation": "https://docs.google.com/presentation/d/105LJog6X4qLZc6Fr_TdY9gMTLhUukbrbE677s9fsW6E"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
6,
@@ -713698,7 +712156,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -714116,6 +712573,14 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -714257,13 +712722,10 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -714294,7 +712756,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -714354,6 +712815,22 @@
0,
0,
0,
+ 2,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -714471,6 +712948,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -714654,6 +713139,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -714678,6 +713167,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -714747,46 +713240,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -714821,9 +713274,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -714833,37 +713283,54 @@
0,
0,
0,
+ 2,
0
]
},
{
"session": {
- "id": "synthetic-melodies-a-digital-soundscape",
- "sourceId": "EZ3EVX",
- "title": "Synthetic Melodies: A Digital Soundscape",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience! Dive into the bleeps and bloops curated by RBRD, weaving together experimental, ambient and IDM. Let’s connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
+ "id": "tales-from-interop",
+ "sourceId": "UQPDPQ",
+ "title": "Tales from interop",
+ "description": "A deep dive into the interop process for Pectra and how it evolved over the year. Find out how 100 people can work on 3 forks at the same time and how we avoided the devops bottlenecks.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "tags": [
+ "Core Protocol",
+ "Security",
+ "Testing",
+ "devops",
+ "Core Protocol",
+ "Security",
+ "Testing"
+ ],
+ "keywords": [
+ "DevOps"
+ ],
+ "duration": 1433,
"language": "en",
- "speakers": [],
+ "sources_swarmHash": "383122b77f86b227e151f74387c9f010ac758d64fca5abea34685147c14c417d",
+ "sources_youtubeId": "NHsi-lyOEUA",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673326163a168eb53561c36a.vtt",
+ "transcript_text": " So today we're going to talk about tales from Interop. The main point is how do we get core devs, so about 120 people, working on roughly five forks to not make everything super chaotic. So before we start, I'm going to set the stage a little bit. What is Pektra? So Pektra is the fork after Denkun. Denkun is the one that we shipped in March of 2024. That's with 4844. The scoping discussions kind of started earlier this year compared to the previous times. So we already had a general idea of what's going to go in Pektra in Jan of 2024. So client teams kind of started working and kind of started bike sharing what's going to go in. Naturally, since we started early, we over-promised or over-committed what we wanted to do. And by May, we had EIP-3074, which is a version of account abstraction, max effective balance, EOF, PRDAS, as well as a lot of other miscellaneous EIPs that were supposed to go into Pectra. And that's the stage in which we are going to be talking about for most of the talk. And then I'll continue with what Pectra looks like today. SSZ, EPBS, Verkl, as well as Verkl transitions were also features that we wanted to think about and wanted to test over the course of the year. There are different teams working on things at the same time. Specifications are getting updated at the same time. So you're essentially looking for a moving target or you're implementing a moving target. So how do we actually ship this thing? Enter Neuta Interop. So this is an event that was held in Kenya for every client team to participate in. So these are the people that are building the Pektra fork. Just a side note, we also had a Frontiers event in Kenya where we got to meet a lot of local builders, and that was extremely nice, and I hope we continue that type of format in the future. The aim was to work on Pektra as well as all the features that I spoke about earlier, and the idea was to try and figure out all the hard problems, see what we needed to do, and how do we ship it. It's an in-person event, and since most of the client teams are spread around the world, it's invaluable to actually be in the same room. You can figure out a problem within a matter of minutes instead of waiting for the person who lives in Seattle to wake up and spend the next two days figuring it out. There's about 120 people who were invited, and we split it into five work streams. So, Pectra, EOF, Pyrdas, Vercl, and Vercl Transition. And like I mentioned, there's 120 people. We're also a very opinionated bunch, so it's not like 120 people have the same machine. There are people with Arch Linux with disabled kernel modules over there, and we need to make sure that the tools work for them. There are people with Windows machines. We need to make sure that the tools work for them. The five work streams make it hard to keep up with what's going on as well. There's not enough dedicated DevOps people for each client team. It's impossible to keep up with updates. Imagine 120 people messaging you, hey, I pushed this commit. Can you actually deploy it for me?",
"eventId": "devcon-7",
- "slot_start": 1731402000000,
+ "slot_start": 1731403800000,
"slot_end": 1731405600000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1kQVFXulZrmOXmwN9TZ75ma4CYWlC0Kv9WxWB6w0qyAg"
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1EI6PvXpSa-LCMg1S_f31vrLcip8y61g5BqDRGaUIJe0",
+ "resources_slides": null,
+ "speakers": [
+ "parithosh-jayanthi"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -715481,6 +713948,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -715612,6 +714080,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -715630,6 +714099,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -715850,6 +714320,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -716099,10 +714570,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -716176,6 +714644,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -716194,31 +714663,39 @@
},
{
"session": {
- "id": "synto-nikka",
- "sourceId": "ZBSJDY",
- "title": "Synto Nikka",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
- "audience": "Engineering",
- "featured": false,
+ "id": "tending-the-infinite-garden-organizational-culture-in-the-ethereum-ecosystem",
+ "sourceId": "U7SNLQ",
+ "title": "Tending the Infinite Garden: Organizational Culture in the Ethereum Ecosystem",
+ "description": "This presentation will discuss the findings of the academic paper \"Tending the Infinite Garden: Organisational Culture in the Ethereum Ecosystem\" by Dr. Paul-Dylan-Ennis and Ann Brody. Our study examines the decision-making processes fundamental to Ethereum's protocol governance, drawing on interviews with Ethereum's core developers. We identify a central worldview in Ethereum known as the \"Infinite Garden\" and discuss how Ethereum's social layer is crucial for upholding cypherpunk values.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Developer",
+ "featured": true,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Ethereum",
+ "Core",
+ "Development;",
+ "Social",
+ "Layer;",
+ "Governance;",
+ "Values"
+ ],
+ "tags": [
+ "value"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "ann-brody"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731492000000,
+ "slot_start": 1731495600000,
"slot_end": 1731497400000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1qlDffU55LOyqC5g5m_XelYjXsBTWIYahAHtzcqgHwic"
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1f-XpVYzA-AiFID7laGqTa-L6kAXqGezXQRCWQw-a-L4"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -716837,6 +715314,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -717340,8 +715818,7 @@
0,
0,
0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -717532,10 +716009,11 @@
2,
0,
0,
- 2,
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -717550,48 +716028,49 @@
},
{
"session": {
- "id": "tackling-east-asias-population-decline-issues-with-local-coops-subsystem-for-local-governance",
- "sourceId": "QKMVPC",
- "title": "Tackling East Asia's Population Decline Issues with Local Coop's Subsystem for Local Governance",
- "description": "Local Coop envisions a world beyond nation-states and capitalism, fostering mutual aid and co-creation. It promotes self-reliant community autonomy and public goods, targeting East Asia's declining population. The system includes digital resident IDs with NFTs, democratizes emissions trading, and manages resources sustainably. Partnerships with local governments facilitate transferring public goods and services to Local Coop, optimized through technology and resident participation.",
- "track": "Real World Ethereum",
+ "id": "the-10-most-common-vulnerabilities-found-in-audit-contests",
+ "sourceId": "LYFXZN",
+ "title": "The 10 Most Common Vulnerabilities Found in Audit Contests",
+ "description": "This lightning talk offers a quick survival guide for DApp developers and security experts, highlighting the most common vulnerabilities found in audit contests. As these contests are often the final step before mainnet, the identified vulnerabilities have typically been overlooked by multiple developers and auditors. The session includes a link to a guide on fixing each vulnerability and a 2-minute Q&A to explore any of the 10 vulnerabilities in more detail and discuss why they are often missed",
+ "track": "Security",
"type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Local/SEA",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Population Decline",
- "Local Government",
- "NFT",
- "Public Service"
- ],
"tags": [
- "Public good",
- "Local Impact",
- "service",
- "public",
- "Autonomous World",
- "Local Impact",
- "Public good"
+ "Security",
+ "Auditing",
+ "audit",
+ "contest",
+ "Auditing",
+ "Security"
],
- "language": "en",
- "speakers": [
- "atsushi-hayashiatsu"
+ "keywords": [
+ "Vulnerabilities;",
+ "Audit",
+ "Contests"
],
+ "duration": 595,
+ "language": "en",
+ "sources_swarmHash": "3103f2e82576803c887da36c890760dec4bb346076f23924fe2e0ecaf42099a0",
+ "sources_youtubeId": "MT7mYhwgksI",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731573600000,
- "slot_end": 1731574200000,
+ "slot_start": 1731408000000,
+ "slot_end": 1731408600000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/105LJog6X4qLZc6Fr_TdY9gMTLhUukbrbE677s9fsW6E"
+ "resources_presentation": "https://docs.google.com/presentation/d/1_iMeu-TIt6aOehgouo5xQOCb89l5Su5oE2WffTDcOII",
+ "resources_slides": null,
+ "speakers": [
+ "jack-sanford"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -718207,34 +716686,11 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -718364,6 +716820,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -718447,8 +716904,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -718517,6 +716972,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -718581,7 +717037,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -718640,6 +717095,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -718774,7 +717230,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -718802,7 +717257,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -718857,6 +717311,19 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -718901,7 +717368,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -718916,64 +717382,72 @@
0,
0,
2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0
]
},
{
"session": {
- "id": "tales-from-interop",
- "sourceId": "UQPDPQ",
- "title": "Tales from interop",
- "description": "A deep dive into the interop process for Pectra and how it evolved over the year. Find out how 100 people can work on 3 forks at the same time and how we avoided the devops bottlenecks.",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "the-age-of-account-abstraction-opportunities-and-challenges",
+ "sourceId": "EPN9S7",
+ "title": "The Age of Account Abstraction: Opportunities and Challenges",
+ "description": "In a world where the web3 user experience is streamlined through account abstraction, complexities like gas and multiple L1s/L2s are hidden from users. This talk explores the competitive dynamics likely to develop at each layer of the stack (layers, DeFi protocols, intent protocols) and the strategies that might be employed to succeed. Join me to delve into the transformative impact of making Web3 seamless and accessible, and understand how to navigate and thrive in this evolving landscape.",
+ "track": "Usability",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Business",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Core Protocol",
- "Security",
- "Testing",
- "devops",
- "Core Protocol",
- "Security",
- "Testing"
- ],
"keywords": [
- "DevOps"
+ "Protocol competition",
+ "User growth",
+ "Layer specialisation"
+ ],
+ "tags": [
+ "Layer 2s",
+ "Account Abstraction",
+ "Intents",
+ "specialisation",
+ "layer",
+ "Account Abstraction",
+ "Intents",
+ "Layer 2s"
],
- "duration": 1433,
"language": "en",
- "sources_swarmHash": "383122b77f86b227e151f74387c9f010ac758d64fca5abea34685147c14c417d",
- "sources_youtubeId": "NHsi-lyOEUA",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673326163a168eb53561c36a.vtt",
- "transcript_text": " So today we're going to talk about tales from Interop. The main point is how do we get core devs, so about 120 people, working on roughly five forks to not make everything super chaotic. So before we start, I'm going to set the stage a little bit. What is Pektra? So Pektra is the fork after Denkun. Denkun is the one that we shipped in March of 2024. That's with 4844. The scoping discussions kind of started earlier this year compared to the previous times. So we already had a general idea of what's going to go in Pektra in Jan of 2024. So client teams kind of started working and kind of started bike sharing what's going to go in. Naturally, since we started early, we over-promised or over-committed what we wanted to do. And by May, we had EIP-3074, which is a version of account abstraction, max effective balance, EOF, PRDAS, as well as a lot of other miscellaneous EIPs that were supposed to go into Pectra. And that's the stage in which we are going to be talking about for most of the talk. And then I'll continue with what Pectra looks like today. SSZ, EPBS, Verkl, as well as Verkl transitions were also features that we wanted to think about and wanted to test over the course of the year. There are different teams working on things at the same time. Specifications are getting updated at the same time. So you're essentially looking for a moving target or you're implementing a moving target. So how do we actually ship this thing? Enter Neuta Interop. So this is an event that was held in Kenya for every client team to participate in. So these are the people that are building the Pektra fork. Just a side note, we also had a Frontiers event in Kenya where we got to meet a lot of local builders, and that was extremely nice, and I hope we continue that type of format in the future. The aim was to work on Pektra as well as all the features that I spoke about earlier, and the idea was to try and figure out all the hard problems, see what we needed to do, and how do we ship it. It's an in-person event, and since most of the client teams are spread around the world, it's invaluable to actually be in the same room. You can figure out a problem within a matter of minutes instead of waiting for the person who lives in Seattle to wake up and spend the next two days figuring it out. There's about 120 people who were invited, and we split it into five work streams. So, Pectra, EOF, Pyrdas, Vercl, and Vercl Transition. And like I mentioned, there's 120 people. We're also a very opinionated bunch, so it's not like 120 people have the same machine. There are people with Arch Linux with disabled kernel modules over there, and we need to make sure that the tools work for them. There are people with Windows machines. We need to make sure that the tools work for them. The five work streams make it hard to keep up with what's going on as well. There's not enough dedicated DevOps people for each client team. It's impossible to keep up with updates. Imagine 120 people messaging you, hey, I pushed this commit. Can you actually deploy it for me?",
- "eventId": "devcon-7",
- "slot_start": 1731403800000,
- "slot_end": 1731405600000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1EI6PvXpSa-LCMg1S_f31vrLcip8y61g5BqDRGaUIJe0",
- "resources_slides": null,
"speakers": [
- "parithosh-jayanthi"
- ]
+ "daniel-yanev"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731552300000,
+ "slot_end": 1731552900000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/17eyZChjX1qpt1_WuQIDXpXi06_RixZQtwAbNNS22vqU"
},
"vector": [
0,
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -719715,10 +718189,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -719734,7 +718204,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -719770,9 +718239,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -719783,6 +718254,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -719956,7 +718428,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -720075,6 +718546,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -720276,14 +718748,15 @@
0,
0,
0,
+ 0,
2,
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -720298,37 +718771,39 @@
},
{
"session": {
- "id": "tending-the-infinite-garden-organizational-culture-in-the-ethereum-ecosystem",
- "sourceId": "U7SNLQ",
- "title": "Tending the Infinite Garden: Organizational Culture in the Ethereum Ecosystem",
- "description": "This presentation will discuss the findings of the academic paper \"Tending the Infinite Garden: Organisational Culture in the Ethereum Ecosystem\" by Dr. Paul-Dylan-Ennis and Ann Brody. Our study examines the decision-making processes fundamental to Ethereum's protocol governance, drawing on interviews with Ethereum's core developers. We identify a central worldview in Ethereum known as the \"Infinite Garden\" and discuss how Ethereum's social layer is crucial for upholding cypherpunk values.",
- "track": "Cypherpunk & Privacy",
+ "id": "the-age-of-aggregation",
+ "sourceId": "VVTWM7",
+ "title": "The Age Of AGGREGATION",
+ "description": "Aggregation plays a critical role in enhancing the usability and scalability of blockchain technology. In this session, we will explore the fundamental concepts of aggregation, debunk common myths, and discuss the necessity of aggregated blockchain systems for achieving real-world usage. Current scalability boundaries limit blockchain's potential, but through aggregation, we can optimize performance and usability, making blockchain technology accessible to a broader audience",
+ "track": "Layer 2",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Developer",
- "featured": true,
+ "audience": "Product",
+ "featured": false,
"doNotRecord": false,
"keywords": [
- "Ethereum",
- "Core",
- "Development;",
- "Social",
- "Layer;",
- "Governance;",
- "Values"
+ "Blockchain optimization",
+ "performance enhancement",
+ "scalability"
],
"tags": [
- "value"
+ "Protocol Design",
+ "Scalability",
+ "Token bridging",
+ "User Experience",
+ "Protocol Design",
+ "Token bridging",
+ "User Experience"
],
"language": "en",
"speakers": [
- "ann-brody"
+ "marc-boiron"
],
"eventId": "devcon-7",
- "slot_start": 1731495600000,
- "slot_end": 1731497400000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1f-XpVYzA-AiFID7laGqTa-L6kAXqGezXQRCWQw-a-L4"
+ "slot_start": 1731645000000,
+ "slot_end": 1731646800000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/19GjAOPnXoMBNpAerM--poOFpPMM-IeprVNBtTrgK-UA"
},
"vector": [
0,
@@ -720336,11 +718811,9 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -721098,6 +719571,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -721127,6 +719601,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -721220,6 +719695,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -721282,6 +719758,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -721457,11 +719934,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -721650,9 +720122,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -721666,49 +720138,61 @@
},
{
"session": {
- "id": "the-10-most-common-vulnerabilities-found-in-audit-contests",
- "sourceId": "LYFXZN",
- "title": "The 10 Most Common Vulnerabilities Found in Audit Contests",
- "description": "This lightning talk offers a quick survival guide for DApp developers and security experts, highlighting the most common vulnerabilities found in audit contests. As these contests are often the final step before mainnet, the identified vulnerabilities have typically been overlooked by multiple developers and auditors. The session includes a link to a guide on fixing each vulnerability and a 2-minute Q&A to explore any of the 10 vulnerabilities in more detail and discuss why they are often missed",
- "track": "Security",
+ "id": "the-blind-mans-elephant-a-product-vision-towards-private-identities",
+ "sourceId": "GSZKVK",
+ "title": "The Blind Man's Elephant: a product vision towards private identities",
+ "description": "A short talk introducing the concepts of key properties we want to achieve in private ZK identities. Sparkling concepts like SSI and DIDs and why blockchains are the best way to ensure that.\r\n\r\nFinally it concludes with simple ZK and data-structure constructions and different alternatives that are seeking to provide this characteristics.\r\n\r\nIn short, this is a lightning overview of the space, it's desired features and different approaches to achieve them.",
+ "track": "Applied Cryptography",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"tags": [
- "Security",
- "Auditing",
- "audit",
- "contest",
- "Auditing",
- "Security"
+ "Privacy",
+ "Identity",
+ "ZKP",
+ "Use Cases",
+ "selective",
+ "disclosure",
+ "Identity",
+ "Privacy",
+ "Use Cases",
+ "ZKP"
],
"keywords": [
- "Vulnerabilities;",
- "Audit",
- "Contests"
+ "Selective-disclosure"
],
- "duration": 595,
+ "duration": 706,
"language": "en",
- "sources_swarmHash": "3103f2e82576803c887da36c890760dec4bb346076f23924fe2e0ecaf42099a0",
- "sources_youtubeId": "MT7mYhwgksI",
+ "sources_swarmHash": "849d3e4fd5ed45afc927a10bae59624aead23e6e86dad6d8ff724046c4df13b9",
+ "sources_youtubeId": "-BESF3MUM20",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
"transcript_vtt": "No VTT link provided",
"transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731408000000,
- "slot_end": 1731408600000,
+ "slot_start": 1731395400000,
+ "slot_end": 1731396000000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1_iMeu-TIt6aOehgouo5xQOCb89l5Su5oE2WffTDcOII",
+ "resources_presentation": "https://docs.google.com/presentation/d/1OM2zZQsD8haiBnMdAS98Oz90Cmk3F2nH7dY0H_hjKTA",
"resources_slides": null,
"speakers": [
- "jack-sanford"
+ "andy"
]
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
6,
0,
0,
@@ -722321,6 +720805,9 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
0,
0,
0,
@@ -722333,7 +720820,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -722461,7 +720947,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -722496,6 +720981,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -722520,8 +721007,11 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
+ 2,
0,
0,
0,
@@ -722558,6 +721048,15 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -722613,7 +721112,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -722737,7 +721235,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -722914,48 +721411,22 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 2,
0,
0,
0,
@@ -723026,7 +721497,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -723039,45 +721509,51 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "the-age-of-account-abstraction-opportunities-and-challenges",
- "sourceId": "EPN9S7",
- "title": "The Age of Account Abstraction: Opportunities and Challenges",
- "description": "In a world where the web3 user experience is streamlined through account abstraction, complexities like gas and multiple L1s/L2s are hidden from users. This talk explores the competitive dynamics likely to develop at each layer of the stack (layers, DeFi protocols, intent protocols) and the strategies that might be employed to succeed. Join me to delve into the transformative impact of making Web3 seamless and accessible, and understand how to navigate and thrive in this evolving landscape.",
+ "id": "the-chain-abstraction-master-plan",
+ "sourceId": "DCSCA7",
+ "title": "The Chain Abstraction Master Plan",
+ "description": "Chain abstraction is vital for Ethereum’s future competitiveness and interoperability. This talk will dive into why Ethereum apps need chain abstraction to avoid fragmentation and ensure open, trustless, and modular systems. We’ll explore approaches to abstraction, the importance of open standards, and a roadmap for upgrading the ecosystem’s core infrastructure—spanning JSON-RPC API improvements, resource locks, and intent settlement—to unlock new layers of usability and decentralization.",
"track": "Usability",
- "type": "Lightning Talk",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Business",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Protocol competition",
- "User growth",
- "Layer specialisation"
+ "Chain Abstraction",
+ "OneBalance",
+ "Resource Locks"
],
"tags": [
- "Layer 2s",
- "Account Abstraction",
- "Intents",
- "specialisation",
- "layer",
"Account Abstraction",
+ "Cross-L2",
+ "Developer Infrastructure",
+ "DevEx",
+ "Ethereum Roadmap",
+ "Gas",
"Intents",
- "Layer 2s"
+ "MEV",
+ "Paymaster",
+ "Rollups",
+ "Token bridging",
+ "Transaction fees mechanisms",
+ "User Experience"
],
"language": "en",
"speakers": [
- "daniel-yanev"
+ "stephane-gosselin"
],
"eventId": "devcon-7",
- "slot_start": 1731552300000,
- "slot_end": 1731552900000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/17eyZChjX1qpt1_WuQIDXpXi06_RixZQtwAbNNS22vqU"
+ "slot_start": 1731576600000,
+ "slot_end": 1731577800000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1aMlbfC7Va_bqN5fI43BFPOB0iIennWgUwyiQxb7D3q0"
},
"vector": [
0,
@@ -723703,8 +722179,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -723833,6 +722307,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -723846,6 +722321,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -723859,6 +722335,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -723868,13 +722345,9 @@
0,
0,
0,
+ 2,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -723886,7 +722359,7 @@
2,
0,
0,
- 0,
+ 2,
2,
0,
0,
@@ -723898,9 +722371,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -724027,6 +722497,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -724034,8 +722505,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -724059,6 +722532,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -724191,7 +722665,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -724259,6 +722732,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -724327,7 +722801,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -724400,8 +722873,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -724415,39 +722888,35 @@
},
{
"session": {
- "id": "the-age-of-aggregation",
- "sourceId": "VVTWM7",
- "title": "The Age Of AGGREGATION",
- "description": "Aggregation plays a critical role in enhancing the usability and scalability of blockchain technology. In this session, we will explore the fundamental concepts of aggregation, debunk common myths, and discuss the necessity of aggregated blockchain systems for achieving real-world usage. Current scalability boundaries limit blockchain's potential, but through aggregation, we can optimize performance and usability, making blockchain technology accessible to a broader audience",
- "track": "Layer 2",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Product",
+ "id": "the-chain-mail-gaze",
+ "sourceId": "73SKE9",
+ "title": "The Chain Mail Gaze",
+ "description": "With their dreams of new ‘Network State’ empires, resource extraction, and colonial domination, today’s tech overlords are the descendants of Europe’s mediaeval Crusaders: well-financed, zealous fanatics remaking the world in the name of their greater good. Through a psycho-political reading of scarcity, chauvinism, and colonialism, The Chain Mail Gaze connects Crusader ideologues’ desire for blood, land, and booty, to emerging ‘frontiers’ mediated by contemporary technologies.",
+ "track": "Coordination",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Blockchain optimization",
- "performance enhancement",
- "scalability"
+ "decolonial"
],
"tags": [
- "Protocol Design",
- "Scalability",
- "Token bridging",
- "User Experience",
- "Protocol Design",
- "Token bridging",
- "User Experience"
+ "Governance",
+ "Network State",
+ "decolonial",
+ "Governance",
+ "Network State"
],
"language": "en",
"speakers": [
- "marc-boiron"
+ "wassim-z-alsindi"
],
"eventId": "devcon-7",
- "slot_start": 1731645000000,
- "slot_end": 1731646800000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/19GjAOPnXoMBNpAerM--poOFpPMM-IeprVNBtTrgK-UA"
+ "slot_start": 1731409800000,
+ "slot_end": 1731410400000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/17RnVgqUzy-db9C_X4-QKgghgKSZ40O-5PtTPVJladMk"
},
"vector": [
0,
@@ -724457,13 +722926,11 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -725218,7 +723685,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -725248,8 +723714,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -725298,6 +723764,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -725342,7 +723809,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -725405,7 +723871,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -725698,6 +724163,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -725763,15 +724229,15 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -725785,52 +724251,31 @@
},
{
"session": {
- "id": "the-blind-mans-elephant-a-product-vision-towards-private-identities",
- "sourceId": "GSZKVK",
- "title": "The Blind Man's Elephant: a product vision towards private identities",
- "description": "A short talk introducing the concepts of key properties we want to achieve in private ZK identities. Sparkling concepts like SSI and DIDs and why blockchains are the best way to ensure that.\r\n\r\nFinally it concludes with simple ZK and data-structure constructions and different alternatives that are seeking to provide this characteristics.\r\n\r\nIn short, this is a lightning overview of the space, it's desired features and different approaches to achieve them.",
- "track": "Applied Cryptography",
+ "id": "the-challenges-of-leaving-laboratory-outbreaks-to-scientists",
+ "sourceId": "TPLHFG",
+ "title": "The challenges of leaving laboratory outbreaks to scientists",
+ "description": "NA",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Expert",
+ "audience": "Academic",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Privacy",
- "Identity",
- "ZKP",
- "Use Cases",
- "selective",
- "disclosure",
- "Identity",
- "Privacy",
- "Use Cases",
- "ZKP"
- ],
- "keywords": [
- "Selective-disclosure"
- ],
- "duration": 706,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "849d3e4fd5ed45afc927a10bae59624aead23e6e86dad6d8ff724046c4df13b9",
- "sources_youtubeId": "-BESF3MUM20",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731395400000,
- "slot_end": 1731396000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1OM2zZQsD8haiBnMdAS98Oz90Cmk3F2nH7dY0H_hjKTA",
- "resources_slides": null,
"speakers": [
- "andy"
- ]
+ "alina-chan"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731568200000,
+ "slot_end": 1731568800000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1p9hSMYlq5ABHla4brR0sibxE7RLsOTyxT95WWe9_UTQ"
},
"vector": [
0,
+ 6,
0,
0,
0,
@@ -725840,7 +724285,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -726455,9 +724899,31 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
- 6,
0,
0,
0,
@@ -726631,7 +725097,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -726657,11 +725122,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -726698,7 +725161,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -727078,23 +725540,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -727142,11 +725587,6 @@
0,
0,
0,
- 0,
- 2,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -727157,6 +725597,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -727165,45 +725606,44 @@
},
{
"session": {
- "id": "the-chain-abstraction-master-plan",
- "sourceId": "DCSCA7",
- "title": "The Chain Abstraction Master Plan",
- "description": "Chain abstraction is vital for Ethereum’s future competitiveness and interoperability. This talk will dive into why Ethereum apps need chain abstraction to avoid fragmentation and ensure open, trustless, and modular systems. We’ll explore approaches to abstraction, the importance of open standards, and a roadmap for upgrading the ecosystem’s core infrastructure—spanning JSON-RPC API improvements, resource locks, and intent settlement—to unlock new layers of usability and decentralization.",
- "track": "Usability",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Product",
+ "id": "the-combination-of-zkp-mpc-fhe",
+ "sourceId": "XPLVT8",
+ "title": "The combination of ZKP +/- MPC +/- FHE",
+ "description": "This talk will provide you with the necessary intuition to understand when you should use ZKP, MPC or FHE, or any combination of them.",
+ "track": "Applied Cryptography",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Chain Abstraction",
- "OneBalance",
- "Resource Locks"
- ],
"tags": [
- "Account Abstraction",
- "Cross-L2",
- "Developer Infrastructure",
- "DevEx",
- "Ethereum Roadmap",
- "Gas",
- "Intents",
- "MEV",
- "Paymaster",
- "Rollups",
- "Token bridging",
- "Transaction fees mechanisms",
- "User Experience"
+ "ZKP",
+ "MPC",
+ "fhe",
+ "MPC",
+ "ZKP"
],
- "language": "en",
- "speakers": [
- "stephane-gosselin"
+ "keywords": [
+ "FHE"
],
+ "duration": 521,
+ "language": "en",
+ "sources_swarmHash": "7724dd5759a7e9323aa0eff8393fff2e9afee7739808254312ba965d6a194a18",
+ "sources_youtubeId": "Tq7CVqDE_P4",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f6fc80d989c5b7ab6204.vtt",
+ "transcript_text": " Yeah, it's working. Okay, cool. So, hello everyone. I'm Giacomo, and I work as a software engineer at PSETM. So, as many of you know, the last few years have seen a huge generational shift in cryptography. We passed from specialized to general-purpose cryptography. And this has brought exciting new opportunities for everyone to make it more practical, but this comes at a cost. The cost is that we should navigate lots of jargon and mathematic, and to get the big picture also for people that is experienced in the field, it's pretty hard, like navigating the protocols, primitives, languages, tooling, etc. So today we'll try to do something very difficult to give just an overview but we will stay a really high level general purpose in order to understand what the building blocks of programmable cryptography can bring and we will just focus on the programmable part instead of the cryptography which is how things work under the hood because we do not have much time so yeah zero knowledge proof so at zero knowledge proofs make one party the prover able to prove to another party the verifier that the statement is true without revealing any information beyond the mere fact of the statements validity so you can use this for example to prove your age that is is true without revealing any information beyond the mere fact of the statement's validity. So you can use this, for example, to prove your age that is above some sort of threshold without saying exactly what your age is. Secure multi-party computation is a set of cryptographic protocols that let multiple parties collaborate together to compute a function providing their inputs, maintaining those inputs for all the computation private. This is useful for use cases like voting, when you have to vote on something, and you want to keep your vote private, and you do not want to trust a third party to count the votes. Then we have FHE, Philemon Morphic Encryption, a set of cryptographic tools that enables you to do encrypted computations. What encrypted computation means is that once decrypted, you get a plain text. And this plain text is the same as if it performed the computation on the decrypted data directly. This is ideal for scenarios like autosourcing computation, like running a machine learning model without letting the model owner learn about your data. Each of these blocks is pretty powerful by its own, but they open up fascinating possibilities by combining them. In particular, on trying to solve their own drawbacks. For example, ZKP can be seen as an efficient, app-specific MPC, but combining them, you can obtain verifying the MPC computation, able to prove that the multi-party computation was performed correctly under some assumption in ZK. So instead of just computing, you can also prove from input to output the computation, or you can outsource the computation. So you can rely on other people doing the computation for you, like they can be like more than one people, and this can enable complex cryptography also in resource-constrained devices because you're not computing by yourself. Another combination, MPC-FHE, like one of the biggest challenges in FHE is managing the decryption keys. And there are two main approaches. The first one is with MPC distributing the key generation. So you have multiple parties, and they can jointly manage a single FHE key where no single party has the ownership of the key generation, so you have multiple parties, and they can jointly and manage a single FHE key, where no single party has the ownership of the key. And the multi-key FHE, everyone has a key, and they should combine the key to perform the secure computation. On the other hand, since FHE is just addition, multiplication of ciphertext. You can achieve sum of product of encrypted values, so you can build generic MPC. With ZQP and FHE is the most experimental and is basically trying to tackle two questions. The first one is, how can I trust that the encrypted value was correct under some assumptions, like is a correct BFE ciphertext? Or how can I trust that the computation value was correct under some assumptions, like is a correct BFE cipher text, or I can trust that the computation was done correctly. And all three blocks combined is like you can combine them. It's technically feasible. We can add ZKey to make very feasible MPC-FHE combination. You can add T's, trusted execution environment, to the ZKey and participate in the MPC-FHE, but we still need to take into consideration that many real-world problems can be solved with just one vanilla block, like just ZKey or MPC, and defining resources, constraints, and unique needs of your problem can help you navigate all the space of the solutions and help you to make the right choice. I'm running out of time, so thank you. Okay, we have three minutes Q&A. Raise your hand if you have a question. That's a little bit far. I'm gonna try That's why outsource to you Maybe I should give it to you What are the most interesting use cases for every single one of the technologies that you've seen Like the key MPC of each year the combination I mean, is there a combination application yet? Yeah, there are some not applications that, like, I cannot say that they are production ready. There are some explorations and research. So you have mainly, like, tooling that can help you to distribute the key of FHE in MPC or you have like some sort of initial research in verifiable FHE like proving that your ciphertext is encrypted correctly so there are still lots going on and as I said it's hard to keep up with everything so maybe I'm not aware of other stuff but in general yeah I think the most exciting thing is trying to make advancement in the FHV ability because this can be really a breakthrough. And I don't know if I can make another question, but is there any framework yet for full-momorphic encryption with contracts, like for mainnet in Solidity? When contracts like for mainnet in Solidity? When you speak about mainnet in Solidity I think that FHE is mainly off-chain stuff. There are some teams that are working on on-chain FHE as well but yeah you can find like the state-of-the-art in the tooling and developer experience is not like as the key one right now. So there's still lots of work to do in libraries, tooling, and frameworks. Right now there are good libraries, good frameworks, but mainly for experimental research more than going to production. Thank you. Thank you so much. I think we have time for one more question. Thank you for Thank you so much. I think we have time for one more question. Thank you for the presentation. Is FHE general purpose? Can we use it for all kinds of computation? So I'm not 100% sure, but FHE is mostly additions and multiplications, so you can maybe emulate everything with those operations. And so yeah, you can have some sort of general-purpose FHE going on, but all the nuances about like the constraints on how efficient it is or how it can be applied on small devices or other stuff it still depends on what kind of back-end you are going to use yeah I think okay let's give a big hand to Giacomo. Thank you so much. Next up we have Rosalina.",
"eventId": "devcon-7",
- "slot_start": 1731576600000,
- "slot_end": 1731577800000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1aMlbfC7Va_bqN5fI43BFPOB0iIennWgUwyiQxb7D3q0"
+ "slot_start": 1731390000000,
+ "slot_end": 1731390600000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1iRVxAm1tYqEBlFNUqErTPQ1GCnhG1txvgCWdfQbSgpk",
+ "resources_slides": null,
+ "speakers": [
+ "giacomo"
+ ]
},
"vector": [
0,
@@ -727214,6 +725654,8 @@
0,
0,
0,
+ 0,
+ 0,
6,
0,
0,
@@ -727830,11 +726272,11 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -727960,7 +726402,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -727974,7 +726415,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -727988,7 +726428,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -727998,9 +726437,7 @@
0,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
@@ -728009,11 +726446,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -728036,6 +726470,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -728049,6 +726484,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -728150,7 +726586,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -728158,10 +726593,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -728186,7 +726619,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -728325,6 +726757,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -728389,7 +726822,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -728519,7 +726951,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -728531,6 +726962,12 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -728541,38 +726978,40 @@
},
{
"session": {
- "id": "the-chain-mail-gaze",
- "sourceId": "73SKE9",
- "title": "The Chain Mail Gaze",
- "description": "With their dreams of new ‘Network State’ empires, resource extraction, and colonial domination, today’s tech overlords are the descendants of Europe’s mediaeval Crusaders: well-financed, zealous fanatics remaking the world in the name of their greater good. Through a psycho-political reading of scarcity, chauvinism, and colonialism, The Chain Mail Gaze connects Crusader ideologues’ desire for blood, land, and booty, to emerging ‘frontiers’ mediated by contemporary technologies.",
- "track": "Coordination",
+ "id": "the-dacc-vision-balancing-progress-and-protection",
+ "sourceId": "AA8SRQ",
+ "title": "The d/acc Vision: Balancing Progress and Protection",
+ "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Research",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "decolonial"
- ],
- "tags": [
- "Governance",
- "Network State",
- "decolonial",
- "Governance",
- "Network State"
- ],
+ "tags": [],
+ "keywords": [],
+ "duration": 594,
"language": "en",
- "speakers": [
- "wassim-z-alsindi"
- ],
+ "sources_swarmHash": "",
+ "sources_youtubeId": "LKGAKn2RZus",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": "67356cb99dbb7a90e15f86d1",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67356cb99dbb7a90e15f86d1.vtt",
+ "transcript_text": " I will get straight into the one slide that I have today. So last year I wrote this post that introduced this concept of DIAC and in general was basically responding to a lot of the discussion that was happening at the time around techno-optimism, the need to be more optimistic about technology and to appreciate the very positive impact that technology actually has had over the past 10 millennia, and also the extremely positive potential that it has over the next century. And at the same time take seriously some of the risks and also really focus on which technologies are going to do the best possible job of giving us the kind of future that we want while at the same time minimizing and even actively fighting against the risks. One of the arguments that I made is basically that there is this important phenomenon which is the offense-defense balance, right? Basically is it easier to attack or is it easier to defend? And if you have an environment where it's easy to attack, then you almost inevitably have this kind of dark Hobbesian choice between a very powerful sovereign and a very destructive state of anarchy. And it just inherently creates all kinds of very bad political effects on top of creating constant ongoing risk of suffering, right? And at the same time, this is all happening under this backdrop of this discussion about is AI itself, and particularly super intelligent AI, this very big and massive risk? If it is, should we try to slow it down? But then if we do slow it down, then slowing it down forever basically just creates a world that becomes more and more unstable. And so what is the actually resilient and actually long-term stable future that we could be aiming for? And I think this to me is a near and mid-term part of the answer. So in the post that I made last year, I split up defensive technology into four categories. So the first split was the split between the world of atoms and the world of bits. So very famous distinction, might as well just grab it and use it. And within the world of atoms, split it up between macro and micro. And so macro defense, basically you think about physical resilience. And we'll have some very interesting talks later today, including topics on how to massively reduce casualties if some kind of extremely terrible disaster happens to humanity. Micro-defense basically means biodefense, so anti-pandemics. And both myself and a huge number of other really fascinating people will be talking about how we can make our environments vastly more resilient against actually existing and even potential pandemics all without requiring significant changes in individual behavior so you might be pleased to know that this room is actually already passively airborne disease resistant so for example over here you have this i mean box, and the box is HIPAA filter. We have a bunch of these all around the room. And so basically this room becomes vastly more safe against COVID, against any kind of future airborne virus that comes up without requiring anyone to actually notice. And this is one example of the kinds of open and widely accessible, easily deployable, and freedom-preserving technologies that we can deploy that can give humanity an orders of magnitude boost in its resistance against these kinds of threats. These are things that we are not doing today, and these are things that with a surprisingly low amount of investment we could actually do a much better job at. So then on the other side we have the world of bits. And the world of bits, this is a distinction that is I believe unique to me. But I talk about the distinction between cyber defense and info defense. Cyber defense is defense against threats where all reasonable people agree who the attacker is, right? So if a DeFi protocol gets hacked, then obviously the DeFi smart contract doesn't agree that it got hacked, because if it did, it wouldn't have sent any money out. But all reasonable people looking at the situation will agree that, well, yes, there is a hacker, or at the very least, someone who used a very unintended mechanism to get coins out of that system. And so we can talk about cryptography, we can talk about formal verification, blockchains, zero-knowledge proofs, what I call the Egyptian God Protocols, FHE and obfuscation, and also another important thing, hardware security, and actually deploying all of those technologies and actually even applying them at the level of operating systems and making sure that things are much safer than they would be today. And then info defense. So this is where reasonable people can actually disagree on who the attacker is. So one man's misinformation is another man's unjustly suppressed valid point and we need technology to actually help filter through this information and help people identify what kinds of content are more likely to be actually positive and what kinds of content are more likely to be misinformative, misleading, things that even they themselves, if they better understood it, would not want to see, and do so in a way that does not involve empowering a centralized elite that decides on behalf of everyone else what is good and true and what is bad and false. Now, that is all a vision of defense. I think one thing that is also important to talk about here is I added a third dimension in the year since then, right? And I call this the survive-thrive dimension. And here we talk about not just the technologies to protect against the bad stuff, but also actually enabling the positive future, right? So in the bio side, we have longevity. Who here is excited about longevity? So now longevity, and then beside longevity, we also have BCI, and BCI is kind of conveniently beside longevity and open decentralized compute, right? So on the left is making sure a compute is safe, or at the top, making sure a compute is safe. At the bottom is making sure a compute is amazing. And compute and biology together, we get BCI acceleration. And I think one of the really important points that we're going to make is that there's actually a lot of ties between these different spaces. It's all one very big integrated field. A lot of the viral persistence research that's being done in the context of long COVID right now actually has a lot of tie-ins that are very applicable to aging, right? So there's recent new theories that viral persistence actually is a thing that's a very big contributor to Alzheimer's. And then BCI, better medical technology, it contributes to fighting diseases, it can contribute to living longer under, quote, normal conditions, and it's also a BCI accelerator. Now, physical abundance. So we want the big silver punk cities, we want housing to be affordable. We want, you know, housing to follow Moore's Law instead of following Eroom's Law, for those who know what those are. And then, you know, we want to go to space. We want everything about our physical environments to not just be resilient but also be affordable and amazing. And finally, collaboration technology. So even in situations where people are not attacking each other, where you actually do have reasonable people and communities that have high trust between each other but they do want to be able to more quickly and more effectively agree on things and come to new consensus if we want agree on things and come to new consensus if we want decentralized collectives to like actually be able to act like life players and make bold choices and keep adapting themselves to rapidly changing circumstances without that collapsing into a dictatorship then much more powerful collaboration technology. So this includes all of the stuff we've been doing around public goods funding. It includes quadratic voting, other forms of voting, futarchy, all kinds of different governance ideas. So basically I think there are natural tie-ins at all sides of this between technologies that can create an environment where everything is much more safe and much more resilient by default and an environment where we have open, distributed and widely available progress for everyone. And so this is what all of the speeches that we're going to see today are going to be about. And I'm very excited to be with you and listen to them. Thank you. And so now I'll introduce our next speaker, Eli Dorado.",
"eventId": "devcon-7",
- "slot_start": 1731409800000,
- "slot_end": 1731410400000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/17RnVgqUzy-db9C_X4-QKgghgKSZ40O-5PtTPVJladMk"
+ "slot_start": 1731553200000,
+ "slot_end": 1731553800000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/105T9qheqDS91uBB6zsLjkTZKkqteIemZL0l9pkz8eJo",
+ "resources_slides": null,
+ "speakers": [
+ "vitalik-buterin"
+ ]
},
"vector": [
0,
+ 6,
0,
0,
0,
@@ -728583,8 +727022,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -728762,6 +727199,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -729201,7 +727639,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -729371,7 +727808,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -729420,7 +727856,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -729822,7 +728257,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -729902,38 +728336,44 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "the-challenges-of-leaving-laboratory-outbreaks-to-scientists",
- "sourceId": "TPLHFG",
- "title": "The challenges of leaving laboratory outbreaks to scientists",
- "description": "NA",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "Expert",
- "audience": "Academic",
+ "id": "the-daos-of-the-east",
+ "sourceId": "BUKGLV",
+ "title": "The DAOs of the East",
+ "description": "DAOs are growing fast in East Asia, and they work very differently from DAOs in the West. From regional revitalization in Japan to Taiwan's digital ministry to the Chinese diaspora, I'll cover many examples and what they mean for the global community of DAOs.",
+ "track": "Coordination",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Asia"
+ ],
+ "tags": [
+ "DAO",
+ "Collective Intelligence",
+ "Regulation",
+ "asia",
+ "Collective Intelligence",
+ "DAO"
+ ],
"language": "en",
"speakers": [
- "alina-chan"
+ "joshua-tan"
],
"eventId": "devcon-7",
- "slot_start": 1731568200000,
- "slot_end": 1731568800000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1p9hSMYlq5ABHla4brR0sibxE7RLsOTyxT95WWe9_UTQ"
+ "slot_start": 1731492000000,
+ "slot_end": 1731493800000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/185nuWRZn9PaXkbj3mmudjiul9XhVrRireCzXcJBlu4Y"
},
"vector": [
- 0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -729945,6 +728385,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -730716,6 +729157,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -730782,11 +729224,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -731132,6 +729576,36 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -731212,96 +729686,66 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
2,
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0
]
},
{
"session": {
- "id": "the-combination-of-zkp-mpc-fhe",
- "sourceId": "XPLVT8",
- "title": "The combination of ZKP +/- MPC +/- FHE",
- "description": "This talk will provide you with the necessary intuition to understand when you should use ZKP, MPC or FHE, or any combination of them.",
- "track": "Applied Cryptography",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Developer",
+ "id": "the-dave-fraud-proof-algorithm-triumphing-over-sybils-with-a-laptop-and-a-small-collateral",
+ "sourceId": "C7ZFH3",
+ "title": "The Dave fraud-proof algorithm — triumphing over Sybils with a laptop and a small collateral",
+ "description": "Current fraud-proof algorithms are susceptible to Sybil attacks, impacting security, decentralization, and (settlement) liveness. This presentation introduces _Dave_, a novel algorithm that offers an unprecedented combination of these three properties. We demonstrate that there's no realistic Sybil attack capable of exhausting defenders' resources or causing significant delays, even with minimal bond requirements.",
+ "track": "Layer 2",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"tags": [
- "ZKP",
- "MPC",
- "fhe",
- "MPC",
- "ZKP"
+ "Optimistic rollups",
+ "fraud",
+ "proof",
+ "Optimistic",
+ "rollups"
],
"keywords": [
- "FHE"
+ "Interactive",
+ "fraud",
+ "proofs"
],
- "duration": 521,
+ "duration": 1393,
"language": "en",
- "sources_swarmHash": "7724dd5759a7e9323aa0eff8393fff2e9afee7739808254312ba965d6a194a18",
- "sources_youtubeId": "Tq7CVqDE_P4",
+ "sources_swarmHash": "f6b19521b73dd026fbdfe1a938aa2a58f1b3e9332c026eba6e6fdd0cc69e350a",
+ "sources_youtubeId": "dI_3neyXVl0",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f6fc80d989c5b7ab6204.vtt",
- "transcript_text": " Yeah, it's working. Okay, cool. So, hello everyone. I'm Giacomo, and I work as a software engineer at PSETM. So, as many of you know, the last few years have seen a huge generational shift in cryptography. We passed from specialized to general-purpose cryptography. And this has brought exciting new opportunities for everyone to make it more practical, but this comes at a cost. The cost is that we should navigate lots of jargon and mathematic, and to get the big picture also for people that is experienced in the field, it's pretty hard, like navigating the protocols, primitives, languages, tooling, etc. So today we'll try to do something very difficult to give just an overview but we will stay a really high level general purpose in order to understand what the building blocks of programmable cryptography can bring and we will just focus on the programmable part instead of the cryptography which is how things work under the hood because we do not have much time so yeah zero knowledge proof so at zero knowledge proofs make one party the prover able to prove to another party the verifier that the statement is true without revealing any information beyond the mere fact of the statements validity so you can use this for example to prove your age that is is true without revealing any information beyond the mere fact of the statement's validity. So you can use this, for example, to prove your age that is above some sort of threshold without saying exactly what your age is. Secure multi-party computation is a set of cryptographic protocols that let multiple parties collaborate together to compute a function providing their inputs, maintaining those inputs for all the computation private. This is useful for use cases like voting, when you have to vote on something, and you want to keep your vote private, and you do not want to trust a third party to count the votes. Then we have FHE, Philemon Morphic Encryption, a set of cryptographic tools that enables you to do encrypted computations. What encrypted computation means is that once decrypted, you get a plain text. And this plain text is the same as if it performed the computation on the decrypted data directly. This is ideal for scenarios like autosourcing computation, like running a machine learning model without letting the model owner learn about your data. Each of these blocks is pretty powerful by its own, but they open up fascinating possibilities by combining them. In particular, on trying to solve their own drawbacks. For example, ZKP can be seen as an efficient, app-specific MPC, but combining them, you can obtain verifying the MPC computation, able to prove that the multi-party computation was performed correctly under some assumption in ZK. So instead of just computing, you can also prove from input to output the computation, or you can outsource the computation. So you can rely on other people doing the computation for you, like they can be like more than one people, and this can enable complex cryptography also in resource-constrained devices because you're not computing by yourself. Another combination, MPC-FHE, like one of the biggest challenges in FHE is managing the decryption keys. And there are two main approaches. The first one is with MPC distributing the key generation. So you have multiple parties, and they can jointly manage a single FHE key where no single party has the ownership of the key generation, so you have multiple parties, and they can jointly and manage a single FHE key, where no single party has the ownership of the key. And the multi-key FHE, everyone has a key, and they should combine the key to perform the secure computation. On the other hand, since FHE is just addition, multiplication of ciphertext. You can achieve sum of product of encrypted values, so you can build generic MPC. With ZQP and FHE is the most experimental and is basically trying to tackle two questions. The first one is, how can I trust that the encrypted value was correct under some assumptions, like is a correct BFE ciphertext? Or how can I trust that the computation value was correct under some assumptions, like is a correct BFE cipher text, or I can trust that the computation was done correctly. And all three blocks combined is like you can combine them. It's technically feasible. We can add ZKey to make very feasible MPC-FHE combination. You can add T's, trusted execution environment, to the ZKey and participate in the MPC-FHE, but we still need to take into consideration that many real-world problems can be solved with just one vanilla block, like just ZKey or MPC, and defining resources, constraints, and unique needs of your problem can help you navigate all the space of the solutions and help you to make the right choice. I'm running out of time, so thank you. Okay, we have three minutes Q&A. Raise your hand if you have a question. That's a little bit far. I'm gonna try That's why outsource to you Maybe I should give it to you What are the most interesting use cases for every single one of the technologies that you've seen Like the key MPC of each year the combination I mean, is there a combination application yet? Yeah, there are some not applications that, like, I cannot say that they are production ready. There are some explorations and research. So you have mainly, like, tooling that can help you to distribute the key of FHE in MPC or you have like some sort of initial research in verifiable FHE like proving that your ciphertext is encrypted correctly so there are still lots going on and as I said it's hard to keep up with everything so maybe I'm not aware of other stuff but in general yeah I think the most exciting thing is trying to make advancement in the FHV ability because this can be really a breakthrough. And I don't know if I can make another question, but is there any framework yet for full-momorphic encryption with contracts, like for mainnet in Solidity? When contracts like for mainnet in Solidity? When you speak about mainnet in Solidity I think that FHE is mainly off-chain stuff. There are some teams that are working on on-chain FHE as well but yeah you can find like the state-of-the-art in the tooling and developer experience is not like as the key one right now. So there's still lots of work to do in libraries, tooling, and frameworks. Right now there are good libraries, good frameworks, but mainly for experimental research more than going to production. Thank you. Thank you so much. I think we have time for one more question. Thank you for Thank you so much. I think we have time for one more question. Thank you for the presentation. Is FHE general purpose? Can we use it for all kinds of computation? So I'm not 100% sure, but FHE is mostly additions and multiplications, so you can maybe emulate everything with those operations. And so yeah, you can have some sort of general-purpose FHE going on, but all the nuances about like the constraints on how efficient it is or how it can be applied on small devices or other stuff it still depends on what kind of back-end you are going to use yeah I think okay let's give a big hand to Giacomo. Thank you so much. Next up we have Rosalina.",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673430199dbb7a90e1d5c737.vtt",
+ "transcript_text": " Tanya Cushman Reviewer:\"Presenter's note\": Hello, can you all hear me? Okay, I'm Gabriel. And today we're going to be talking fraud proofs, you know, like another session about fraud proofs. We will present a new technique that we've just published, in fact, so it's been in the oven for quite a while, and I'm quite excited to show it to you all. But the bottom line is that we weren't quite happy on the current set of fraud truths, so we created a new algorithm. So first I'd like to thank Cartesi for all the grants provided, and also my co-authors, Augusto, who is here on the audience, and Diego. So thank you all, and also to all the organizers of this amazing event. Yeah, so first I want to get this question out of the way, the ZK question. It may feel that when we're talking about fraud proofs, that we're trying to figure out the best grass to feed our horses, and I want to push back against that notion, you know, because there are no silver bullets. You know, ZK is not panacea. When you compare them with front roofs, there's a sharp contrast in throughput and costs, which means that depending on the application, you're going to prefer the different algorithms, you know, there are going to be trade-offs in the end. There's no silver bullets. That's the point I wanted to get across. for the different algorithms. There are going to be trade-offs in the end. There's no silver bullets. That's the point I wanted to get across. So now let's focus on fraud proofs. Yeah. The agenda today is that they're actually quite hard to get. I hope you got that notion from Luca's talk. All the previous attempts were either unsafe, centralized, or slow, and Dave is not. Yeah, so fraud proofs are in a difficult position right now. So we have the pressure, you know, on the top there's Vitalik's tweet, essentially calling for stricter standards, but if we look at L2B, we don't see full pizzas, right? So we have the pressure, but we don't have implementations coming. And the reason for that is because it's actually quite hard to get fraud proofs right. And the reason for that is because it's actually quite hard to get fraud proofs right. And by right, I mean essentially three properties. The first, we're there. I want you to be able to become a validator. I want you to be able to go there without a supercomputer, without huge bonds, and be able to participate in the consensus, in the protocol. And the second property is that I want that you be able to participate in the consensus, in the protocol. And the second property is that I want that you be able to defeat anyone by yourself, even if you're facing against a nation state. So if you get those two properties to defend an optimistic roll-up, all you have to do is set up a node on your own infrastructure. You don't need to delegate trust to anybody else. We inherit the security of the base layer. So those are like the two, like, one event property, and we want it to be decentralized. And the next one is that we want settlement to happen without large delays. We want settlement to happen quickly. So let me run all the three of them together. They kind of look like this. You know, decentralization. I want you to be able to participate without a supercomputer or huge bonds. There's security, which means the TVL cannot be stolen, even if you're facing against this nation state. And liveness. No large delays. And you might be getting some flashbacks, you know, like some PTSD, like, oh, no, do we have another trilemma? And, yeah, kind of, you know. It's actually quite hard to get the three of them at the same time. And you can always naively go from one vertex to the other. But you sacrifice one to gain the other. So you can't take this straight off. So it does look like a real trilemma. And the reason for that is Sybil attacks. I will zoom in on only the first one, which is resource exhaustion attacks. It's like a spam attack where you create a huge number of Sybils and you just drain the funds of the honest validator until they can no longer participate in the game and then you can steal the TVL. So this is a Sybil attack that targets the security of the algorithm. And there are mitigation strategies, but they end up restricting participation and thus harming decentralization. So there are three main solutions that we will talk today. There are several others, but we'll talk about these two. The first two is by Optimism, Optimism Fault Proof. There's also Arbitrum's Bold. And our own permissionless referee tournaments, PRT for short. This is the previous algorithm we did. That was our first attempt at cracking this. And I want to highlight the very important fact that the top two, you know, the first two, if you look at the TVL distribution on L2Beat, pretty much most of it is being protected by those first two. You know, it's either an OP chain or an arbitrage chain. So we need to keep this in mind because we need to take the analysis of these algorithms quite seriously. So this is a sneak peek comparison between, you know, those three and the one we're going to present today. And the columns, they map directly to those three properties. So, for example, bonds, if you look at bold, you need 3,600 ETH to become a validator. So it's a very high bond value. And this has a centralization effect. So the bond column is related to centralization, decentralization. Now, expenses. Oh, just to,, just to highlight this. This is a one million Ether attack scenario. So we assume that the adversary is willing to burn that amount of money. In that case, if it's a OP fault proof, the defender has to match those funds. So if you don't have also one million Ether, you will lose that EVL. So that column expenses maps to security 1 million Ether, you will lose that CVL. So that column expenses maps to security. And finally, we have delay. If you look at our own, if there's this 1 million Ether attack, you get 20 weeks delay, which is also quite high. So none of the three we feel are quite adequate. And today we will present Dave, which is on the bottom, which strikes a good balance across all three of them. Cool. So let's talk about some basic concepts of fraud proofs. Okay, so first our threat model. We assume that the layer one works. However, we also assume that it can be censored for up to one week. So think like a censorship budget that the adversary has, and they can spend it at will. And we also assume there is one honest validator, which we're going to say it's Willy. And Willy has a laptop, a few ether, and values, hard values. So we begin with the basic primitive, which is a pairwise refutation. So, the goal is that, well, you have two players. You have your Willy, the adversary, and the blockchain acting as a referee in the middle. And those two will engage in a dispute to prove that the other is wrong. And in the end, the goal is to prove the result of a program to the referee. And it's interesting because they don't prove the correct result directly. They prove that the other is incorrect. And since we assume Will is there, he's the one who's going to enforce the right result. Because he's the honest one, you know. Yeah, so they're going to fight to prove the correct result of a program. Now, what do we mean by program? The computation model has an initial state and a state transition function, agreed by everyone, and then we apply the state transition function over and over the initial state until we get the final state. And that final state is the result of the program. That's what we are trying to prove to the blockchain. And the intuition of a refutation game is that first we're going to perform a binary search on this computation and try to pinpoint the exact state transition that they first disagreed on. Because if they agree before and disagree after, somewhere in the middle, they started disagreeing. And we want to pinpoint exactly that, and once you find that divergence, you can execute a single state transition function, you know, the referee, the blockchain, and figure out who's lying and eliminate this liar. So this is the basic intuition, but we're going to make a slight change to this. So instead of committing just to the final state, which is really what we're interested about, we are going instead to make a commitment on the whole history of the computation. So we have all these transient states and we're going to commit to that. So it's like a Merkle tree where the leaves are all the transient states. We Merkle-ize that, we get the claim, so we turn the dispute not just on the final state but also on the history. And this change is important because we remove the possibility of false flag attacks, which are quite annoying, you know? So we can join claims that are the same together on the same thing. And this enables a whole bunch of algorithms, including PRT, because we introduced this technique on PRT, and Dave, which we're going to present today. Now, the final piece, to get all the primitives, is deadlines, because it's an interactive protocol. So players act in turns, and if they refuse to act, we need to do something. So we need to set deadlines to eliminate players who are not cooperating. But remember, we have the one-week censorship in our threat model. So naively, we would have to set a one-week for each interaction, which would kill the liveness of any protocol. So what we instead do, this is a technique that many protocols use, is something like a chess clock. So this allows you to amortize this one week across many interactions instead of having to pay it for every single interaction. So you turn from the seven-day multiplying each interaction for it to be an additive part of the expression. And then you only need to pay for each interaction the real time of that interaction in the absence of censorship. Because an interaction is quite fast. It's like five minutes. And we don't want to pay on top of that five minutes seven days. So we use the chess clock to amortize that. Now let's generalize this. This is a pairwise refutation first. Now let's do a multi-party refutation. And there are two high-level approaches. One is the parallel approach, which is more like what Bold uses. And the good part of it is that it finishes fast. So we have Willy engaging every other claim in parallel at the same time. But the problem is that we incurred a chance of overwhelming Willy, right? So imagine that instead of only five, we had like one million Sybils. We'd have Willy trying to fight everybody at the same time, and he could get overwhelmed and lose and lose a TVL. So we have this, you know, oh, it's fast, but it might overwhelm Willy. And we can mitigate that by increasing bonds, but then we start centralizing the algorithm. With PRT, which is our previous algorithm, we went a different route. We used this tournament idea, right? So we put symbols to fight against other symbols. So the number of rounds is logarithmic, the expenses are logarithmic, and the delay is logarithmic. So this all means exponential advantage. Willy has an exponential advantage on delay and resources. But each round takes a week because of the censorship. You know, even amortizing the week across a match, every match, every round still has to last at least a week. So if we imagine this, the analogous of one million symbols here, there will be 20 rounds. So it will take 20 weeks, which is high, you know? But matches only take two hours in practice. In the absence of censorship, they would take two hours. But because there could be censorship, we need to add the week. So we were thinking, oh, why don't we try to amortize this one week, not only inside a single round, but across the entire dispute. So this is what we'll try to do. So what I'll present now is an attempt to accomplish that. Okay, so the algorithm is called DAVE, and it's just DAVE. It's not an acronym. It's based on the David versus Goliath archetype. Because, anyway. So the first change we make is we change the tournament to a repechage tournament. This is a fancy name just to mean matches are not eliminatory. You don't eliminate a claim as soon as it loses. You give it a while. It has to lose multiple times before it's finally eliminated. So this is what repressage means. Now don't try to think about how long this will take. Forget that. Let's just think on the soundness of it. I want on this slide to convince you that Willy won't lose and he will defeat everybody. Let's think about time later. So imagine that we have the censorship of one week, but we reduce the rounds, the matches to one day. So every one day Dave rematches everybody, including Willy, and then they fight. The next day, rematches everybody again, and so on. We know that Willy can't lose unless there's censorship, but even if there's censorship, we know that Willy can't lose more than seven times because the budget is only seven days. So it's like Willy has eight hit points, but the adversary has only seven bullets. So the best the adversary can do is spend his whole budget and force Willy to lose seven hit points. And then he's out of budget. And now Willy is very angry indeed and is going to kill everybody else. Now this may seem a bit abstract, so let's get it more concrete. So this is a different example. The previous one was with eight hit points. This one is just three. The optimal value is more like 21, you know, but it's hard to visualize that. So let's go with three first. Yeah, so everybody's on the same bucket in the beginning. Everyone has three HP. And the white arrows point to the matchmaking. So Willy is paired against red, and green is paired against gray. So red and green lose, so they are demoted. Then we rematch again. Now this time Willy is against gray, red is against green. So green loses, gray loses, and it keeps going like this, you know, this logic of pairing whoever loses gets demoted. And eventually, Willy wins, you know, he kills everyone. But on this example note that we assume there's no censorship, so Willy didn't lose any hearts. He could have lost hearts, but it's, you know, it would take more images to do that. So we're just assuming that there's no censorship for this figure. But there could be. So Willy could lose two rounds, but not the third one. But we didn't talk about how this matchmaking is done. And this is quite delicate, in fact. This is at the heart of Dave, the matchmaking. We can't do it randomly. We cannot do this adversarially, Byzantine, you know. It has to be done in a very specific way, which is we need to do matchmaking by hit point. So we want to match the same hit point with same hit point, or at least as close as possible. So looking back, it's the same image, you know. We did the correct matchmaking. So on the second round, Dave is matched, not Dave, Willie. Willie is matched against the gray one. He's not matched against red or green. Has to be matched with gray. Third round is not possible to do a perfect pairing. So we do our best. And our best would be either gray or red. And so on. So like abstractly, it's like as if we sorted every claim by hit point, highest to lowest, and then we'd match them left to right. Yeah, and when we do that, we actually get exactly what we wanted. You know, if it was random, there would be no improvements over PRT. But if we do the rematching with similar HP, we actually dilute the seven days across the whole dispute. We get exactly what we wanted. There's some constants there. That's why I said proportional. It's not exactly that. But the idea is really we are amortizing seven days across the whole dispute. And we're only paying one day in that seven day example you know that I gave earlier times logarithmic of symbols. I mean the real values is actually more like 10 hours you know then there's a constant. We go on all of that for a lot more nuance and discussions on the paper so we can check it out. Yeah so this finishes the description of Dave. So it's a repashage tournament where we do the matchmaking with similar HP. And when we do that, we amortize the seven days across the whole dispute instead of over a single round. So concluding, you can be Willy. You only need the laptop and about a three-eater collateral. You can defeat anyone because you have this exponential advantage. So this means that a roll-up that uses Dave inherits the security of L1. And for any realistic Sybil attacks, it's going to take no more than four weeks. It's going to be within four weeks. And thus Dave triumphed over the Sybils with a laptop and a small collector. But Dave had no supercomputers on his hands. And we got those results. Yeah, that's all I had to present to you today. Thank you very much for coming. Great talk. Love the name Dave. Thank you. He's got a few Q&A questions. He can still add some of the questions while we're going through some of these and upvote them. But the first question is one that I've been thinking too. What if there's multiple willies defending? Won't they eliminate each other? Yeah, so that's a good question. When we did the computation hash, which is that commitment, it means that everybody that's honest is going to be on the same team. So if there are many willies, they will fight together against the symbols, not against each other, because they claim the same thing. So we have this uniqueness of claims when we do the computation hash, and we allow all the honest validators to join teams. So we consider this singleton hero, it's just Willy, but in practice there are going to be many Willys and they all fight together pushing in the same direction. Cool. Next question is about your censorship model. Is your censorship model hard censorship? And do inclusion lists improve these things? Yeah, so the inclusion lists, I don't think they help exactly on that. So the censorship model, you know, Luca gave a very good intuition of it, is that seven days is the time we can try to organize a hard fork. So suppose there is hard censorship. My transactions are not getting to the blockchain. So what's going to happen is that, you is that Twitter is going to catch on fire and going to scream to everybody, look, I'm being censored for already four days. Everybody is going to get iffy about this and we are going to together organize like a hard fork or something to fix this. So the point is not that there can't be a seven-day censorship. It is that if there is a seven-week censorship, the Ethereum community will together realize and say that this is a problem and then hard fork away. And if we put like a one-day censorship, I would convince nobody. Seven days, it's the threshold that we consider to be easy to convince. Cool. The next question. What happens to levels in the current PRT? Will your plans be to eliminate it with a ZK? Yeah, exactly. So PRT, if you look at our current implementation, we are doing it with three levels. We think with some really good engineering effort, we can do it in two. We want to do it in one using ZK. Exactly that. And this is a prerequisite of Dave. So Dave already assumes that we managed to reduce this to one level. Cool. So what happens if you mix algorithms together? Would that increase security? Do you see it working? Yeah. So there are two ways to mix algorithms. One of them is to improve liveness actually. So PRT finishes faster if there are very few number of symbols. So what we could do is launch PRT in parallel with Dave. If there are very few symbols, PRT finishes first. If there are a lot of symbols, Dave finishes first. So then we take whoever answers first. So this is an approach to improve on liveness. Now, to improve on security, we can also mix them with the goal of reducing the risk of a bug. So we could have a consortium, like a quorum of four members. One member could be PRT, but permissioned. So permissioned PRT, but permissioned. So permissioned PRT has no problems of liveness, so we could have that one of the members in the forum. Then we could have Dave as another member in the forum. Then we could have, I don't know, a TEE or a quorum of TEEs, and then we could have a multisig, you know? So if we have this quorum of many, it would take a lot of effort to try to corrupt all of them at the same time. So we reduce the risk by reducing the chance of there being a bug. So that's how you could mix protocols. Cool. So what if the goal is not to disrupt the chain, but just to delay the chain? How large would the cost be if the attacker presuming the only goal is to delay by four weeks? So if you want to delay by four weeks, I think you need more than $10 billion or something. We have to burn the GDP of Japan. It's crazy. We sometimes lose sight of exponential or logarithmic. So really, if you burn trillions, you can't even fit that on the blockchain, then you couldn't really push past these four or five weeks. The next one, asymptotically is it still logarithmatic delay, right? Yeah, exactly. What we did is we reduced the constant multiplying it by about one order of magnitude. Okay. We have multiple willies that are good, but then I decide to go bad. They can't because when they do a bisection, they need to provide the Merkle proof, and the proofs won't just match. They'll just not match. Cool. All right. Everyone clap your hands for Gabriel and thank him for his time he spent on this talk. Thank you so much. The next session will be at 11.30.",
"eventId": "devcon-7",
- "slot_start": 1731390000000,
- "slot_end": 1731390600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1iRVxAm1tYqEBlFNUqErTPQ1GCnhG1txvgCWdfQbSgpk",
+ "slot_start": 1731470400000,
+ "slot_end": 1731472200000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1GhOQePXCr0xuShvpJcgSNAMhIC_wT2B34JYiogZJB7s",
"resources_slides": null,
"speakers": [
- "giacomo"
+ "gabriel-coutinho-de-paula",
+ "augusto-teixeira"
]
},
"vector": [
@@ -731312,9 +729756,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -731937,6 +730378,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -732124,6 +730566,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -732132,9 +730575,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -732146,7 +730586,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -732283,6 +730722,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -732402,6 +730842,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -732420,7 +730861,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -732554,6 +730994,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -732622,8 +731064,6 @@
0,
2,
0,
- 0,
- 0,
2,
0,
0,
@@ -732635,41 +731075,42 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "the-dacc-vision-balancing-progress-and-protection",
- "sourceId": "AA8SRQ",
- "title": "The d/acc Vision: Balancing Progress and Protection",
- "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "id": "the-end-game-wallet-when-does-abstraction-go-too-far",
+ "sourceId": "ZTMLMQ",
+ "title": "The End Game Wallet: When Does Abstraction Go Too Far?",
+ "description": "Chain abstraction has taken the front seat. As innovations continue, it's becoming increasingly stark that we will eventually approach a world where third-party solvers fulfill most transactions. The core protocol is also changing to cater to further abstractions even at the validator level. The question remains, how far are we willing to go in the name of efficiency, and optimizations, to which a user can't use Ethereum without third parties?",
+ "track": "Usability",
"type": "Lightning Talk",
- "expertise": "",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "n/a"
+ ],
+ "tags": [
+ "Values",
+ "UI/UX",
+ "UI/UX",
+ "Values"
+ ],
"language": "en",
"speakers": [
- "vitalik-buterin"
+ "gregthegreek"
],
"eventId": "devcon-7",
- "slot_start": 1731553200000,
- "slot_end": 1731553800000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/105T9qheqDS91uBB6zsLjkTZKkqteIemZL0l9pkz8eJo"
+ "slot_start": 1731556800000,
+ "slot_end": 1731557400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Yvp0nywauCOnCqYI14BUwqz77qWUB-SScBhTcicFGtg"
},
"vector": [
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -732678,6 +731119,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -732853,7 +731295,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -733300,6 +731741,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -733477,6 +731919,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -733541,6 +731984,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -733980,6 +732424,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -733998,44 +732443,41 @@
},
{
"session": {
- "id": "the-daos-of-the-east",
- "sourceId": "BUKGLV",
- "title": "The DAOs of the East",
- "description": "DAOs are growing fast in East Asia, and they work very differently from DAOs in the West. From regional revitalization in Japan to Taiwan's digital ministry to the Chinese diaspora, I'll cover many examples and what they mean for the global community of DAOs.",
- "track": "Coordination",
- "type": "Talk",
+ "id": "the-end-of-self-custodial-wallets",
+ "sourceId": "KDUNLM",
+ "title": "The end of self-custodial wallets",
+ "description": "This talk provides a quick overview of how countries worldwide restrict or plan to ban the self-custodial ownership model, which is the foundation of cryptocurrencies.\r\n\r\n- What kind of laws, regulations and guidance countries have passed to restrict self-custodial\r\n- What kind of areas are being targeted: ownership of cryptocurrencies, wallets, developers, interfaces\r\n- Who are the driving forces behind opposing self-custodial\r\n- How to counteract this development",
+ "track": "Cypherpunk & Privacy",
+ "type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Business",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Asia"
+ "Self custodial",
+ "FATF",
+ "wallet"
],
"tags": [
- "DAO",
- "Collective Intelligence",
+ "Free Speech",
+ "Censorship Resistance",
"Regulation",
- "asia",
- "Collective Intelligence",
- "DAO"
+ "fatf",
+ "Censorship Resistance",
+ "Free Speech",
+ "Regulation"
],
"language": "en",
"speakers": [
- "joshua-tan"
+ "mikko-ohtamaa"
],
"eventId": "devcon-7",
- "slot_start": 1731492000000,
- "slot_end": 1731493800000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/185nuWRZn9PaXkbj3mmudjiul9XhVrRireCzXcJBlu4Y"
+ "slot_start": 1731647400000,
+ "slot_end": 1731648000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Ap05BLrc25kR-WdwGvInSGF6oehwIIAg82A0vs0Krrg"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -734662,16 +733104,12 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -734883,54 +733321,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -734944,6 +733334,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -734984,6 +733375,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -735238,7 +733630,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -735334,6 +733725,54 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -735345,7 +733784,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -735357,6 +733795,13 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -735365,47 +733810,35 @@
},
{
"session": {
- "id": "the-dave-fraud-proof-algorithm-triumphing-over-sybils-with-a-laptop-and-a-small-collateral",
- "sourceId": "C7ZFH3",
- "title": "The Dave fraud-proof algorithm — triumphing over Sybils with a laptop and a small collateral",
- "description": "Current fraud-proof algorithms are susceptible to Sybil attacks, impacting security, decentralization, and (settlement) liveness. This presentation introduces _Dave_, a novel algorithm that offers an unprecedented combination of these three properties. We demonstrate that there's no realistic Sybil attack capable of exhausting defenders' resources or causing significant delays, even with minimal bond requirements.",
- "track": "Layer 2",
+ "id": "the-evolution-of-zk-from-1985-2013",
+ "sourceId": "FGXMGH",
+ "title": "The Evolution of ZK from 1985-2013",
+ "description": "This session delves into the rich history of zero-knowledge proofs (ZKPs), tracing key milestones from their inception in 1985 to groundbreaking advancements like simulation extractability and the first non-interactive zero-knowledge protocol (NIZK), the first SNARK protocol, etc. While many advances happened within the crypto space, it is beneficial to be aware about the evolution of ZK prior to us inheriting it from the theoretical world.",
+ "track": "Applied Cryptography",
"type": "Talk",
"expertise": "Expert",
- "audience": "Research",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Optimistic rollups",
- "fraud",
- "proof",
- "Optimistic",
- "rollups"
- ],
"keywords": [
- "Interactive",
- "fraud",
- "proofs"
+ "history"
+ ],
+ "tags": [
+ "Zero-Knowledge",
+ "Cryptography",
+ "history",
+ "Cryptography",
+ "Zero-Knowledge"
],
- "duration": 1393,
"language": "en",
- "sources_swarmHash": "f6b19521b73dd026fbdfe1a938aa2a58f1b3e9332c026eba6e6fdd0cc69e350a",
- "sources_youtubeId": "dI_3neyXVl0",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673430199dbb7a90e1d5c737.vtt",
- "transcript_text": " Tanya Cushman Reviewer:\"Presenter's note\": Hello, can you all hear me? Okay, I'm Gabriel. And today we're going to be talking fraud proofs, you know, like another session about fraud proofs. We will present a new technique that we've just published, in fact, so it's been in the oven for quite a while, and I'm quite excited to show it to you all. But the bottom line is that we weren't quite happy on the current set of fraud truths, so we created a new algorithm. So first I'd like to thank Cartesi for all the grants provided, and also my co-authors, Augusto, who is here on the audience, and Diego. So thank you all, and also to all the organizers of this amazing event. Yeah, so first I want to get this question out of the way, the ZK question. It may feel that when we're talking about fraud proofs, that we're trying to figure out the best grass to feed our horses, and I want to push back against that notion, you know, because there are no silver bullets. You know, ZK is not panacea. When you compare them with front roofs, there's a sharp contrast in throughput and costs, which means that depending on the application, you're going to prefer the different algorithms, you know, there are going to be trade-offs in the end. There's no silver bullets. That's the point I wanted to get across. for the different algorithms. There are going to be trade-offs in the end. There's no silver bullets. That's the point I wanted to get across. So now let's focus on fraud proofs. Yeah. The agenda today is that they're actually quite hard to get. I hope you got that notion from Luca's talk. All the previous attempts were either unsafe, centralized, or slow, and Dave is not. Yeah, so fraud proofs are in a difficult position right now. So we have the pressure, you know, on the top there's Vitalik's tweet, essentially calling for stricter standards, but if we look at L2B, we don't see full pizzas, right? So we have the pressure, but we don't have implementations coming. And the reason for that is because it's actually quite hard to get fraud proofs right. And the reason for that is because it's actually quite hard to get fraud proofs right. And by right, I mean essentially three properties. The first, we're there. I want you to be able to become a validator. I want you to be able to go there without a supercomputer, without huge bonds, and be able to participate in the consensus, in the protocol. And the second property is that I want that you be able to participate in the consensus, in the protocol. And the second property is that I want that you be able to defeat anyone by yourself, even if you're facing against a nation state. So if you get those two properties to defend an optimistic roll-up, all you have to do is set up a node on your own infrastructure. You don't need to delegate trust to anybody else. We inherit the security of the base layer. So those are like the two, like, one event property, and we want it to be decentralized. And the next one is that we want settlement to happen without large delays. We want settlement to happen quickly. So let me run all the three of them together. They kind of look like this. You know, decentralization. I want you to be able to participate without a supercomputer or huge bonds. There's security, which means the TVL cannot be stolen, even if you're facing against this nation state. And liveness. No large delays. And you might be getting some flashbacks, you know, like some PTSD, like, oh, no, do we have another trilemma? And, yeah, kind of, you know. It's actually quite hard to get the three of them at the same time. And you can always naively go from one vertex to the other. But you sacrifice one to gain the other. So you can't take this straight off. So it does look like a real trilemma. And the reason for that is Sybil attacks. I will zoom in on only the first one, which is resource exhaustion attacks. It's like a spam attack where you create a huge number of Sybils and you just drain the funds of the honest validator until they can no longer participate in the game and then you can steal the TVL. So this is a Sybil attack that targets the security of the algorithm. And there are mitigation strategies, but they end up restricting participation and thus harming decentralization. So there are three main solutions that we will talk today. There are several others, but we'll talk about these two. The first two is by Optimism, Optimism Fault Proof. There's also Arbitrum's Bold. And our own permissionless referee tournaments, PRT for short. This is the previous algorithm we did. That was our first attempt at cracking this. And I want to highlight the very important fact that the top two, you know, the first two, if you look at the TVL distribution on L2Beat, pretty much most of it is being protected by those first two. You know, it's either an OP chain or an arbitrage chain. So we need to keep this in mind because we need to take the analysis of these algorithms quite seriously. So this is a sneak peek comparison between, you know, those three and the one we're going to present today. And the columns, they map directly to those three properties. So, for example, bonds, if you look at bold, you need 3,600 ETH to become a validator. So it's a very high bond value. And this has a centralization effect. So the bond column is related to centralization, decentralization. Now, expenses. Oh, just to,, just to highlight this. This is a one million Ether attack scenario. So we assume that the adversary is willing to burn that amount of money. In that case, if it's a OP fault proof, the defender has to match those funds. So if you don't have also one million Ether, you will lose that EVL. So that column expenses maps to security 1 million Ether, you will lose that CVL. So that column expenses maps to security. And finally, we have delay. If you look at our own, if there's this 1 million Ether attack, you get 20 weeks delay, which is also quite high. So none of the three we feel are quite adequate. And today we will present Dave, which is on the bottom, which strikes a good balance across all three of them. Cool. So let's talk about some basic concepts of fraud proofs. Okay, so first our threat model. We assume that the layer one works. However, we also assume that it can be censored for up to one week. So think like a censorship budget that the adversary has, and they can spend it at will. And we also assume there is one honest validator, which we're going to say it's Willy. And Willy has a laptop, a few ether, and values, hard values. So we begin with the basic primitive, which is a pairwise refutation. So, the goal is that, well, you have two players. You have your Willy, the adversary, and the blockchain acting as a referee in the middle. And those two will engage in a dispute to prove that the other is wrong. And in the end, the goal is to prove the result of a program to the referee. And it's interesting because they don't prove the correct result directly. They prove that the other is incorrect. And since we assume Will is there, he's the one who's going to enforce the right result. Because he's the honest one, you know. Yeah, so they're going to fight to prove the correct result of a program. Now, what do we mean by program? The computation model has an initial state and a state transition function, agreed by everyone, and then we apply the state transition function over and over the initial state until we get the final state. And that final state is the result of the program. That's what we are trying to prove to the blockchain. And the intuition of a refutation game is that first we're going to perform a binary search on this computation and try to pinpoint the exact state transition that they first disagreed on. Because if they agree before and disagree after, somewhere in the middle, they started disagreeing. And we want to pinpoint exactly that, and once you find that divergence, you can execute a single state transition function, you know, the referee, the blockchain, and figure out who's lying and eliminate this liar. So this is the basic intuition, but we're going to make a slight change to this. So instead of committing just to the final state, which is really what we're interested about, we are going instead to make a commitment on the whole history of the computation. So we have all these transient states and we're going to commit to that. So it's like a Merkle tree where the leaves are all the transient states. We Merkle-ize that, we get the claim, so we turn the dispute not just on the final state but also on the history. And this change is important because we remove the possibility of false flag attacks, which are quite annoying, you know? So we can join claims that are the same together on the same thing. And this enables a whole bunch of algorithms, including PRT, because we introduced this technique on PRT, and Dave, which we're going to present today. Now, the final piece, to get all the primitives, is deadlines, because it's an interactive protocol. So players act in turns, and if they refuse to act, we need to do something. So we need to set deadlines to eliminate players who are not cooperating. But remember, we have the one-week censorship in our threat model. So naively, we would have to set a one-week for each interaction, which would kill the liveness of any protocol. So what we instead do, this is a technique that many protocols use, is something like a chess clock. So this allows you to amortize this one week across many interactions instead of having to pay it for every single interaction. So you turn from the seven-day multiplying each interaction for it to be an additive part of the expression. And then you only need to pay for each interaction the real time of that interaction in the absence of censorship. Because an interaction is quite fast. It's like five minutes. And we don't want to pay on top of that five minutes seven days. So we use the chess clock to amortize that. Now let's generalize this. This is a pairwise refutation first. Now let's do a multi-party refutation. And there are two high-level approaches. One is the parallel approach, which is more like what Bold uses. And the good part of it is that it finishes fast. So we have Willy engaging every other claim in parallel at the same time. But the problem is that we incurred a chance of overwhelming Willy, right? So imagine that instead of only five, we had like one million Sybils. We'd have Willy trying to fight everybody at the same time, and he could get overwhelmed and lose and lose a TVL. So we have this, you know, oh, it's fast, but it might overwhelm Willy. And we can mitigate that by increasing bonds, but then we start centralizing the algorithm. With PRT, which is our previous algorithm, we went a different route. We used this tournament idea, right? So we put symbols to fight against other symbols. So the number of rounds is logarithmic, the expenses are logarithmic, and the delay is logarithmic. So this all means exponential advantage. Willy has an exponential advantage on delay and resources. But each round takes a week because of the censorship. You know, even amortizing the week across a match, every match, every round still has to last at least a week. So if we imagine this, the analogous of one million symbols here, there will be 20 rounds. So it will take 20 weeks, which is high, you know? But matches only take two hours in practice. In the absence of censorship, they would take two hours. But because there could be censorship, we need to add the week. So we were thinking, oh, why don't we try to amortize this one week, not only inside a single round, but across the entire dispute. So this is what we'll try to do. So what I'll present now is an attempt to accomplish that. Okay, so the algorithm is called DAVE, and it's just DAVE. It's not an acronym. It's based on the David versus Goliath archetype. Because, anyway. So the first change we make is we change the tournament to a repechage tournament. This is a fancy name just to mean matches are not eliminatory. You don't eliminate a claim as soon as it loses. You give it a while. It has to lose multiple times before it's finally eliminated. So this is what repressage means. Now don't try to think about how long this will take. Forget that. Let's just think on the soundness of it. I want on this slide to convince you that Willy won't lose and he will defeat everybody. Let's think about time later. So imagine that we have the censorship of one week, but we reduce the rounds, the matches to one day. So every one day Dave rematches everybody, including Willy, and then they fight. The next day, rematches everybody again, and so on. We know that Willy can't lose unless there's censorship, but even if there's censorship, we know that Willy can't lose more than seven times because the budget is only seven days. So it's like Willy has eight hit points, but the adversary has only seven bullets. So the best the adversary can do is spend his whole budget and force Willy to lose seven hit points. And then he's out of budget. And now Willy is very angry indeed and is going to kill everybody else. Now this may seem a bit abstract, so let's get it more concrete. So this is a different example. The previous one was with eight hit points. This one is just three. The optimal value is more like 21, you know, but it's hard to visualize that. So let's go with three first. Yeah, so everybody's on the same bucket in the beginning. Everyone has three HP. And the white arrows point to the matchmaking. So Willy is paired against red, and green is paired against gray. So red and green lose, so they are demoted. Then we rematch again. Now this time Willy is against gray, red is against green. So green loses, gray loses, and it keeps going like this, you know, this logic of pairing whoever loses gets demoted. And eventually, Willy wins, you know, he kills everyone. But on this example note that we assume there's no censorship, so Willy didn't lose any hearts. He could have lost hearts, but it's, you know, it would take more images to do that. So we're just assuming that there's no censorship for this figure. But there could be. So Willy could lose two rounds, but not the third one. But we didn't talk about how this matchmaking is done. And this is quite delicate, in fact. This is at the heart of Dave, the matchmaking. We can't do it randomly. We cannot do this adversarially, Byzantine, you know. It has to be done in a very specific way, which is we need to do matchmaking by hit point. So we want to match the same hit point with same hit point, or at least as close as possible. So looking back, it's the same image, you know. We did the correct matchmaking. So on the second round, Dave is matched, not Dave, Willie. Willie is matched against the gray one. He's not matched against red or green. Has to be matched with gray. Third round is not possible to do a perfect pairing. So we do our best. And our best would be either gray or red. And so on. So like abstractly, it's like as if we sorted every claim by hit point, highest to lowest, and then we'd match them left to right. Yeah, and when we do that, we actually get exactly what we wanted. You know, if it was random, there would be no improvements over PRT. But if we do the rematching with similar HP, we actually dilute the seven days across the whole dispute. We get exactly what we wanted. There's some constants there. That's why I said proportional. It's not exactly that. But the idea is really we are amortizing seven days across the whole dispute. And we're only paying one day in that seven day example you know that I gave earlier times logarithmic of symbols. I mean the real values is actually more like 10 hours you know then there's a constant. We go on all of that for a lot more nuance and discussions on the paper so we can check it out. Yeah so this finishes the description of Dave. So it's a repashage tournament where we do the matchmaking with similar HP. And when we do that, we amortize the seven days across the whole dispute instead of over a single round. So concluding, you can be Willy. You only need the laptop and about a three-eater collateral. You can defeat anyone because you have this exponential advantage. So this means that a roll-up that uses Dave inherits the security of L1. And for any realistic Sybil attacks, it's going to take no more than four weeks. It's going to be within four weeks. And thus Dave triumphed over the Sybils with a laptop and a small collector. But Dave had no supercomputers on his hands. And we got those results. Yeah, that's all I had to present to you today. Thank you very much for coming. Great talk. Love the name Dave. Thank you. He's got a few Q&A questions. He can still add some of the questions while we're going through some of these and upvote them. But the first question is one that I've been thinking too. What if there's multiple willies defending? Won't they eliminate each other? Yeah, so that's a good question. When we did the computation hash, which is that commitment, it means that everybody that's honest is going to be on the same team. So if there are many willies, they will fight together against the symbols, not against each other, because they claim the same thing. So we have this uniqueness of claims when we do the computation hash, and we allow all the honest validators to join teams. So we consider this singleton hero, it's just Willy, but in practice there are going to be many Willys and they all fight together pushing in the same direction. Cool. Next question is about your censorship model. Is your censorship model hard censorship? And do inclusion lists improve these things? Yeah, so the inclusion lists, I don't think they help exactly on that. So the censorship model, you know, Luca gave a very good intuition of it, is that seven days is the time we can try to organize a hard fork. So suppose there is hard censorship. My transactions are not getting to the blockchain. So what's going to happen is that, you is that Twitter is going to catch on fire and going to scream to everybody, look, I'm being censored for already four days. Everybody is going to get iffy about this and we are going to together organize like a hard fork or something to fix this. So the point is not that there can't be a seven-day censorship. It is that if there is a seven-week censorship, the Ethereum community will together realize and say that this is a problem and then hard fork away. And if we put like a one-day censorship, I would convince nobody. Seven days, it's the threshold that we consider to be easy to convince. Cool. The next question. What happens to levels in the current PRT? Will your plans be to eliminate it with a ZK? Yeah, exactly. So PRT, if you look at our current implementation, we are doing it with three levels. We think with some really good engineering effort, we can do it in two. We want to do it in one using ZK. Exactly that. And this is a prerequisite of Dave. So Dave already assumes that we managed to reduce this to one level. Cool. So what happens if you mix algorithms together? Would that increase security? Do you see it working? Yeah. So there are two ways to mix algorithms. One of them is to improve liveness actually. So PRT finishes faster if there are very few number of symbols. So what we could do is launch PRT in parallel with Dave. If there are very few symbols, PRT finishes first. If there are a lot of symbols, Dave finishes first. So then we take whoever answers first. So this is an approach to improve on liveness. Now, to improve on security, we can also mix them with the goal of reducing the risk of a bug. So we could have a consortium, like a quorum of four members. One member could be PRT, but permissioned. So permissioned PRT, but permissioned. So permissioned PRT has no problems of liveness, so we could have that one of the members in the forum. Then we could have Dave as another member in the forum. Then we could have, I don't know, a TEE or a quorum of TEEs, and then we could have a multisig, you know? So if we have this quorum of many, it would take a lot of effort to try to corrupt all of them at the same time. So we reduce the risk by reducing the chance of there being a bug. So that's how you could mix protocols. Cool. So what if the goal is not to disrupt the chain, but just to delay the chain? How large would the cost be if the attacker presuming the only goal is to delay by four weeks? So if you want to delay by four weeks, I think you need more than $10 billion or something. We have to burn the GDP of Japan. It's crazy. We sometimes lose sight of exponential or logarithmic. So really, if you burn trillions, you can't even fit that on the blockchain, then you couldn't really push past these four or five weeks. The next one, asymptotically is it still logarithmatic delay, right? Yeah, exactly. What we did is we reduced the constant multiplying it by about one order of magnitude. Okay. We have multiple willies that are good, but then I decide to go bad. They can't because when they do a bisection, they need to provide the Merkle proof, and the proofs won't just match. They'll just not match. Cool. All right. Everyone clap your hands for Gabriel and thank him for his time he spent on this talk. Thank you so much. The next session will be at 11.30.",
- "eventId": "devcon-7",
- "slot_start": 1731470400000,
- "slot_end": 1731472200000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1GhOQePXCr0xuShvpJcgSNAMhIC_wT2B34JYiogZJB7s",
- "resources_slides": null,
"speakers": [
- "gabriel-coutinho-de-paula",
- "augusto-teixeira"
- ]
+ "vanishree-rao"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731656400000,
+ "slot_end": 1731658200000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1sY_h2GBY4R5mcKYTqc0O1AuTzmygnIH1SdXhzmaDIyE"
},
"vector": [
0,
@@ -735415,11 +733848,10 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -736042,7 +734474,6 @@
0,
0,
6,
- 6,
0,
0,
0,
@@ -736171,6 +734602,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -736228,7 +734661,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -736384,7 +734816,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -736505,7 +734936,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -736660,7 +735090,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -736724,11 +735153,12 @@
0,
0,
0,
- 2,
0,
2,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -736743,42 +735173,38 @@
},
{
"session": {
- "id": "the-end-game-wallet-when-does-abstraction-go-too-far",
- "sourceId": "ZTMLMQ",
- "title": "The End Game Wallet: When Does Abstraction Go Too Far?",
- "description": "Chain abstraction has taken the front seat. As innovations continue, it's becoming increasingly stark that we will eventually approach a world where third-party solvers fulfill most transactions. The core protocol is also changing to cater to further abstractions even at the validator level. The question remains, how far are we willing to go in the name of efficiency, and optimizations, to which a user can't use Ethereum without third parties?",
- "track": "Usability",
- "type": "Lightning Talk",
+ "id": "the-fixed-rate-flywheel",
+ "sourceId": "WYWLXV",
+ "title": "The Fixed Rate Flywheel",
+ "description": "In the rapidly evolving landscape of modern DeFi, fixed-rate protocols have emerged as a critical component, bridging the gap between traditional finance stability and DeFi innovation. This panel introduces \"The Fixed Rate Flywheel,\" a powerful concept illustrating how fixed rate markets fuel variable lending, create hedging opportunities, and generate high-yield products. Join us to hear experts from DELV Tech, Morpho Labs, Phoenix Labs, and Gauntlet talk about the next evolution of DeFi.",
+ "track": "Cryptoeconomics",
+ "type": "Panel",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "n/a"
+ "DeFi",
+ "Fixed Rates"
],
"tags": [
- "Values",
- "UI/UX",
- "UI/UX",
- "Values"
+ "fixed",
+ "rate"
],
"language": "en",
"speakers": [
- "gregthegreek"
+ "alex-towle",
+ "merlin-egalite",
+ "lucas-manuel",
+ "violet-vienhage"
],
"eventId": "devcon-7",
- "slot_start": 1731556800000,
- "slot_end": 1731557400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Yvp0nywauCOnCqYI14BUwqz77qWUB-SScBhTcicFGtg"
+ "slot_start": 1731491400000,
+ "slot_end": 1731495000000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ng1HvT-kAE4r-IB_k-m3qkQnZ9PMYl3wwR_zkEmF4Fg"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
6,
@@ -737269,7 +735695,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -737413,6 +735838,10 @@
0,
0,
0,
+ 6,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -737584,7 +736013,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -737649,7 +736077,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -738027,6 +736454,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -738108,39 +736537,33 @@
},
{
"session": {
- "id": "the-end-of-self-custodial-wallets",
- "sourceId": "KDUNLM",
- "title": "The end of self-custodial wallets",
- "description": "This talk provides a quick overview of how countries worldwide restrict or plan to ban the self-custodial ownership model, which is the foundation of cryptocurrencies.\r\n\r\n- What kind of laws, regulations and guidance countries have passed to restrict self-custodial\r\n- What kind of areas are being targeted: ownership of cryptocurrencies, wallets, developers, interfaces\r\n- Who are the driving forces behind opposing self-custodial\r\n- How to counteract this development",
- "track": "Cypherpunk & Privacy",
+ "id": "the-future-of-ai-why-we-need-private-uncensored-permissionless-ai",
+ "sourceId": "EK8T9X",
+ "title": "The Future of AI: Why We Need Private, Uncensored, Permissionless AI",
+ "description": "The current path of AI development leads to a future where a few powerful companies control this transformative technology, with the potential to become the arbiter of truth, manipulate and monetize private user data, and moderate who has access to the future of intelligence.\r\n\r\nNo entity, private or public, should have the power to monopolize or contextualize truth. Open-source, uncensored, and decentralised AI is impervious to political fancy and ideology, and offers a necessary alternative.",
+ "track": "Real World Ethereum",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Business",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Self custodial",
- "FATF",
- "wallet"
+ "AI"
],
"tags": [
- "Free Speech",
"Censorship Resistance",
- "Regulation",
- "fatf",
- "Censorship Resistance",
- "Free Speech",
- "Regulation"
+ "Permissionless",
+ "Privacy"
],
"language": "en",
"speakers": [
- "mikko-ohtamaa"
+ "teana-baker-taylor"
],
"eventId": "devcon-7",
- "slot_start": 1731647400000,
- "slot_end": 1731648000000,
+ "slot_start": 1731564000000,
+ "slot_end": 1731564600000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Ap05BLrc25kR-WdwGvInSGF6oehwIIAg82A0vs0Krrg"
+ "resources_presentation": "https://docs.google.com/presentation/d/1kklsZ1YE71cdtzZNkgKNXlsh133eDOoZO3-I29W9u9s"
},
"vector": [
0,
@@ -738148,10 +736571,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -738778,11 +737199,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -738922,7 +737343,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -739002,7 +737422,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -739012,6 +737431,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -739159,6 +737579,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -739396,7 +737817,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -739463,8 +737883,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -739478,48 +737898,51 @@
},
{
"session": {
- "id": "the-evolution-of-zk-from-1985-2013",
- "sourceId": "FGXMGH",
- "title": "The Evolution of ZK from 1985-2013",
- "description": "This session delves into the rich history of zero-knowledge proofs (ZKPs), tracing key milestones from their inception in 1985 to groundbreaking advancements like simulation extractability and the first non-interactive zero-knowledge protocol (NIZK), the first SNARK protocol, etc. While many advances happened within the crypto space, it is beneficial to be aware about the evolution of ZK prior to us inheriting it from the theoretical world.",
- "track": "Applied Cryptography",
+ "id": "the-future-of-eof-layer-1-layer-2-and-beyond",
+ "sourceId": "9EBQ3H",
+ "title": "The Future of EOF: Layer 1, Layer 2, and Beyond!",
+ "description": "While the EVM Object Format provides a mechanism to modernize the EVM, the container format itself provides a stable path for innovation and experimentation within the base and rollup layers of ethereum, as well as rollup layers, and even chain free execution.\r\n\r\nIn this presentation we will show how the structure of the EOF container may be adapted to support these potential use cases.",
+ "track": "Core Protocol",
"type": "Talk",
- "expertise": "Expert",
- "audience": "Developer",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "history"
+ "EOF",
+ "EVM"
],
"tags": [
- "Zero-Knowledge",
- "Cryptography",
- "history",
- "Cryptography",
- "Zero-Knowledge"
+ "Layer 1",
+ "EVM-equivalent",
+ "Politics",
+ "EVM",
+ "EVM-equivalent",
+ "Layer 1",
+ "Politics"
],
"language": "en",
"speakers": [
- "vanishree-rao"
+ "danno-ferrin"
],
"eventId": "devcon-7",
- "slot_start": 1731656400000,
- "slot_end": 1731658200000,
+ "slot_start": 1731563400000,
+ "slot_end": 1731565200000,
"slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1sY_h2GBY4R5mcKYTqc0O1AuTzmygnIH1SdXhzmaDIyE"
+ "resources_presentation": "https://docs.google.com/presentation/d/1xsXLO6lk8scS1Bau7a1gPEtC1QKpw5GdJrAD2ZppNaI"
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -739843,6 +738266,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -740145,7 +738569,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -740274,10 +738697,6 @@
0,
0,
6,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -740469,6 +738888,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -740584,6 +739004,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -740594,6 +739015,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -740763,8 +739185,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -740822,13 +739242,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
2,
0,
0,
- 2,
0,
0,
0,
@@ -740844,47 +739264,54 @@
},
{
"session": {
- "id": "the-fixed-rate-flywheel",
- "sourceId": "WYWLXV",
- "title": "The Fixed Rate Flywheel",
- "description": "In the rapidly evolving landscape of modern DeFi, fixed-rate protocols have emerged as a critical component, bridging the gap between traditional finance stability and DeFi innovation. This panel introduces \"The Fixed Rate Flywheel,\" a powerful concept illustrating how fixed rate markets fuel variable lending, create hedging opportunities, and generate high-yield products. Join us to hear experts from DELV Tech, Morpho Labs, Phoenix Labs, and Gauntlet talk about the next evolution of DeFi.",
- "track": "Cryptoeconomics",
- "type": "Panel",
+ "id": "the-future-of-layer-2-research-development-and-next-gen-technologies",
+ "sourceId": "PJQQSR",
+ "title": "The Future of Layer 2: Research, Development, and Next-Gen Technologies",
+ "description": "Discussion around L2 blockchain research and development. What are the major challenges for L2s to advance, and what solutions are being explored? What will the L2 space look like next year and beyond? The talk will be illustrated with examples from Arbitrum’s research and development.",
+ "track": "Layer 2",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developper",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "DeFi",
- "Fixed Rates"
- ],
"tags": [
- "fixed",
- "rate"
+ "Layer 2s",
+ "Scalability",
+ "arbitrum",
+ "Layer 2s",
+ "Scalability"
],
- "language": "en",
- "speakers": [
- "alex-towle",
- "merlin-egalite",
- "lucas-manuel",
- "violet-vienhage"
+ "keywords": [
+ "Arbitrum"
],
+ "duration": 1539,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "6GHjgjD9Va8",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731491400000,
- "slot_end": 1731495000000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1ng1HvT-kAE4r-IB_k-m3qkQnZ9PMYl3wwR_zkEmF4Fg"
+ "slot_start": 1731492000000,
+ "slot_end": 1731493800000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1j5n0blTsDLltg5bxumMOQ0zvAqbfL-faBMhuzsnBX3k",
+ "resources_slides": null,
+ "speakers": [
+ "ed-felten"
+ ]
},
"vector": [
0,
0,
- 6,
- 0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -741513,12 +739940,9 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -741695,6 +740119,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -741768,6 +740193,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -742129,10 +740555,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -742193,7 +740618,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -742202,6 +740626,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -742211,33 +740636,30 @@
},
{
"session": {
- "id": "the-future-of-ai-why-we-need-private-uncensored-permissionless-ai",
- "sourceId": "EK8T9X",
- "title": "The Future of AI: Why We Need Private, Uncensored, Permissionless AI",
- "description": "The current path of AI development leads to a future where a few powerful companies control this transformative technology, with the potential to become the arbiter of truth, manipulate and monetize private user data, and moderate who has access to the future of intelligence.\r\n\r\nNo entity, private or public, should have the power to monopolize or contextualize truth. Open-source, uncensored, and decentralised AI is impervious to political fancy and ideology, and offers a necessary alternative.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "id": "the-future-of-light-clients",
+ "sourceId": "UL8U8B",
+ "title": "The Future of Light Clients",
+ "description": "Ethereum has achieved a remarkable feat: production-ready light clients. There are now at least seven light client projects active on Ethereum today.\r\n\r\nHowever, light clients have kept up with Ethereum’s future, Layer 2s. Implementations for layer 2s have been mostly overlooked. This is due to both the low prioritization of work on light clients and significant technical challenges. In this talk, we will discuss the path to layer 2 light clients and our work to bring them to production in Helios.",
+ "track": "Layer 2",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "AI"
- ],
+ "keywords": [],
"tags": [
- "Censorship Resistance",
- "Permissionless",
- "Privacy"
+ "Layer 2s",
+ "Light Clients"
],
"language": "en",
"speakers": [
- "teana-baker-taylor"
+ "noah-citron"
],
"eventId": "devcon-7",
- "slot_start": 1731564000000,
- "slot_end": 1731564600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1kklsZ1YE71cdtzZNkgKNXlsh133eDOoZO3-I29W9u9s"
+ "slot_start": 1731493800000,
+ "slot_end": 1731495600000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/11L_sO6Usnx1os7aiKFPC2mNm1diDnV9Hlo7PETnsic8"
},
"vector": [
0,
@@ -742246,10 +740668,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -743011,6 +741431,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -743055,6 +741477,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -743108,7 +741531,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -743140,7 +741562,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -743257,7 +741678,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -743557,12 +741977,11 @@
0,
2,
0,
+ 2,
0,
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -743575,46 +741994,39 @@
},
{
"session": {
- "id": "the-future-of-eof-layer-1-layer-2-and-beyond",
- "sourceId": "9EBQ3H",
- "title": "The Future of EOF: Layer 1, Layer 2, and Beyond!",
- "description": "While the EVM Object Format provides a mechanism to modernize the EVM, the container format itself provides a stable path for innovation and experimentation within the base and rollup layers of ethereum, as well as rollup layers, and even chain free execution.\r\n\r\nIn this presentation we will show how the structure of the EOF container may be adapted to support these potential use cases.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "the-future-of-web3-grants-learnings-from-studying-30-programs",
+ "sourceId": "F9YCZY",
+ "title": "The Future of Web3 Grants: Learnings from Studying 30+ Programs",
+ "description": "This presentation will cover learnings from studying almost 3 dozen grant programs across multiple chains and ecosystems. I will present an overview of the state of grants across Ethereum as well as Bitcoin, Cardano, Solana, and other chains. I will present on the most pressing challenges for grant operators, feedback from grantees on their experiences, and will present a potential path forward in terms of collective priorities that can help all programs improve.",
+ "track": "Coordination",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "EOF",
- "EVM"
+ "Grant",
+ "Allocation",
+ "Capital"
],
"tags": [
- "Layer 1",
- "EVM-equivalent",
- "Politics",
- "EVM",
- "EVM-equivalent",
- "Layer 1",
- "Politics"
+ "capital"
],
"language": "en",
"speakers": [
- "danno-ferrin"
+ "eugene-leventhal"
],
"eventId": "devcon-7",
- "slot_start": 1731563400000,
- "slot_end": 1731565200000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1xsXLO6lk8scS1Bau7a1gPEtC1QKpw5GdJrAD2ZppNaI"
+ "slot_start": 1731641400000,
+ "slot_end": 1731642000000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1kRi6qfFHeK8txYMq58KLUaOTV4stHccKNP0m-WyZWWg"
},
"vector": [
0,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -743622,6 +742034,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -743944,7 +742357,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -744251,6 +742663,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -744376,7 +742789,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -744568,7 +742980,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -744685,7 +743096,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -744696,7 +743106,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -744866,6 +743275,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -744922,7 +743332,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -744933,6 +743342,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -744944,43 +743355,51 @@
},
{
"session": {
- "id": "the-future-of-layer-2-research-development-and-next-gen-technologies",
- "sourceId": "PJQQSR",
- "title": "The Future of Layer 2: Research, Development, and Next-Gen Technologies",
- "description": "Discussion around L2 blockchain research and development. What are the major challenges for L2s to advance, and what solutions are being explored? What will the L2 space look like next year and beyond? The talk will be illustrated with examples from Arbitrum’s research and development.",
- "track": "Layer 2",
+ "id": "the-history-and-philosophy-of-cypherpunk",
+ "sourceId": "8JVYCQ",
+ "title": "The History and Philosophy of Cypherpunk",
+ "description": "Rather than bend to knee to Donald Trump, the goal of the cypherpunk movement is to abolish the state in order to maximize human freedom via privacy-enhancing decentralized technologie. After reviewing the history of this deviant group of programmers in the 1980s, what philosophical and technical lessons do the cypherpunks hold for Ethereum today? Censorship-resistant digital cash was only one the start, and the missing parts of their legacy: mixnets and anonymous credentials for identity.",
+ "track": "Cypherpunk & Privacy",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Developper",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"tags": [
- "Layer 2s",
- "Scalability",
- "arbitrum",
- "Layer 2s",
- "Scalability"
+ "Anonymity",
+ "Censorship Resistance",
+ "Digital Sovereignty",
+ "cypherpunk",
+ "mixnet",
+ "cryptoanarchy",
+ "Anonymity",
+ "Politics",
+ "Values"
],
"keywords": [
- "Arbitrum"
+ "mixnets",
+ "cypherpunk",
+ "cryptoanarchist"
],
- "duration": 1539,
+ "duration": 1555,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "6GHjgjD9Va8",
+ "sources_swarmHash": "89ddf65d60e9d080ec70f2820e3674c757d151a0741047ec721bd81ba034a27e",
+ "sources_youtubeId": "prXQJSp_H8A",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673351433a168eb5355b5f3c.vtt",
+ "transcript_text": " Okay, so we are here to basically bring back the cypherpunk roots of blockchain technology. I'm Harry, CEO of NIM. And I'm Max, Senior DevRel for NIMH. So also if you want to talk about building anything with NIMH, come find me over the rest of the conference. So I would just like to begin this talk saying that I'm actually very proud of Vitalik in the blog post where he decided he was not going to bend the knee to Donald Trump just because Donald Trump was going to pump everyone's crypto bags. Donald Trump and authoritarian states are the opposite of cypherpunk. It's the opposite of our ethos. The ethos of cypherpunk is based on meritocracy without borders, right? Not nationalism, not kicking out immigrants and all sorts of other complete nonsense. So I think it is a good time to kind of go into the history of how cypherpunk came to be. And we're going to do it a little bit differently. I've seen a lot of talks about, you know, Phil Zimmerman and Eric Hughes and the original cypherpunk movement, but there's a lot of stuff left out. So that's what we're going to go through. I'd like to just give a shout-out to the father, the inventor of the term anarchism, Pierre Proudhon, who had, at the dawn of the Industrial Revolution, many core concepts that now we are only seeing come to fruition. For example, do you know in 1863, Pierre said we can replace the monarchy with self-governing communes and collectives and individuals who will coordinate via contracts and create their own popular banking systems. Of course, he was taken out by Marx, and generally, kind of no one looks at him academically anymore, but there's really old roots. And then a lot of the questions that we are facing today came forward in what's called the socialist calculation debate, where the question was, how is it that we can reorganize society? Should we use money or not? Should we plan in a centralized way or not? And most of Austrian economics, Hayek and Van Mises and all these folks came from this debate as a reaction against the socialists from Vienna like Otto von Neurath who claimed that money does not capture all the externalities in the well-being of population. So it's a really old history that predates cryptography and the invention of computing about these topics. Should we organize in a decentralized way, returning sovereignty and power to individuals and to smaller communities or should we centralize power? If you're interested in more tons of philosophy work here, but the general thesis is that the spread of cryptographic techniques, which were originally the domain of the nation state, because the nation state is based on hierarchies, on the keeping of secrets, keeping of secrets around agriculture, keeping of secrets around military, cryptography let this spread into the general population, and this has been perhaps the most defying change in sovereignty since like essentially ancient sumer go for it max all right so this section of the talk we're going to go through a couple of let's say the more basic like um technological advances that have happened and then i'm going gonna then, these are things that we imagine that kind of everyone here knows about, but we'll do a quick overview and then we'll really jump into the more like the social side of cypherpunk and how this is, how it feeds back into the technology it creates. So in 67, Whitfield, Diffie and Martin Hellman, they kind of introduced public key cryptography into the public domain right so it's just the idea that you can for the first time then you could create a shared secret key with which you could have like secret communication uh over a non-confidential channel beforehand one of the massive problems of actually like setting up any kind of encrypted comms with people was how do you initially share this secret between both of you right this is the public key cryptography as well as being the basis of like tls ssl it's also obviously like the basis of so much of the crypto that we use today uh can we do the next slide all right so then in 79 david charm invented mixnets with untraceable electronic mail return addresses and digital pseudonyms right the t TLDR of this is how do you create an anonymous, untraceable communication network that protects the data of your comms, right? As well as the metadata. So can you create something wherein you can't tell who is talking to who and when? Next one. There we go. And not too long afterwards afterwards he then came out with another concept which is that of anonymous credentials to defend against a dossier society so this first line of this paper from 1985 I think sums it up better than a lot of stuff still sums it up today so computerization is robbing individuals of the ability to monitor and control the ways that information about them is used. So in 85, Charm was already talking about the lack of agency that people were having with regards to the data that was about themselves and how they communicate in the world and could already see the kind of possible dystopia on the horizon. So finally, we had Diffie-Hellman. They allowed people to create, to envisage stuff like Miss Next, which allow you to communicate privately. And then also we have credentials, which allow you to transact privately. These two kind of key cornerstones of like cypherpunk tech that then can be used to envision this kind of better society that we're talking about here. So that was the stuff that I kind of imagined everyone would already know. Now we'll go on to the more fun stuff. So this was Resource One's project, Community Memory. This was the first computerized public bulletin board system. So the first introduction that a lot of people would have had to computing in general uh it was in the people's computing center in san francisco and it was the yeah like i said the first pbs so the first way that people were able to like freely share and spread information using computer systems this is interesting because one of the people who is criminally under talked about in this space uh was also key in not just resource one but also the creation of the people's computing center and that's Jude Milhoon so otherwise known as Saint Jude she was actually the originator of the term cypherpunk itself so the title of this Congress and everything else owes that to her and as well as being a founding member of the Cypherpunks mailing list, she was a civil rights activist. So actually this picture from the Montgomery Police Department is after she got arrested in Montgomery, Alberta, on a civil rights march in 67. And it was broad civil rights activism throughout her entire life. She was also a senior editor of Mondo 2000, which is now Wired, so you can see how both tech and culture is constantly feedbacking, the feedback cycle is tight, basically. And a couple of choice quotes of, hacking is a martial art, a way of defending against politically correct politicians, overly intrusive laws, bigots, and narrow-minded people of all persuasions. These are some of her publications take a picture they're all really fun and good but we don't have that much time and a lot to get through so another piece of culture that fed back into the early cypherpunk movement and became part of as well its true names by Verna Vinger this is a novel which actually has the original use of the word nim in terms of pseudonym or hidden name and was even though it was written in a1 thoroughly predictive of government surveillance of parallel online spaces this then fed into one of the kind of like the author of a series of seminal texts within this, right, which is Tim May. So not only just True Names and Crypto Anarchy, which was an essay that then actually Vinger enjoyed so much, it was included in the late 90s represses of True Names. He was a founding member of the Cypherpunks mailing list, and his, let's say, predictive power to understand both the potential of this tech, so providing the ability for individuals and groups to communicate and interact with each other in a totally anonymous manner is something to bring attention to. Finally, a lesser known, let's say, strain of thought that I think is still foundational to a lot of the cypherpunk ethos that we want to push forward today is that of agorism. So agorism, until fairly recently, when it was revitalized by the Agorist Journal. So check that out at agorism.xyz. Then this was a relatively little-known strain of political political thought but still had a massive impact on the cypherpunk culture this is the idea of a counter economy right so possibly a different way of thinking about what we would maybe call parallel societies or these kind of like non-state these non-state market structures right so his was very much based in anti-statism and kind of went all the way from black markets to gray markets to just unregulated people helping each other out and the novel that's included here alongside night is you could almost think of it as kind of a dramatized thought experiment of a young man who as society is kind of crumbling down, his kind of journey through the agorist underworld to regain, I suppose, freedom in the way that Konkin described it. And I'll kick it back to Harry now. So where things all started getting real for the cypherpunks, it was interesting concepts and everyone here is inheriting this tradition. It was actually, hilariously enough, as the early internet took off, people leaked the secret beliefs of the Church of Scientology, who you may know as a lot of lawyers. And they started trying to go after some of the cypherpunks and crypto-anarchists. And this led to the invention of what was called the Cypherpunk Anonymous Remailer. So you took emails, put them in PGP, sent them to the computer, stripped off the header and sent them out. However, unfortunately, those Cypherpunk remailers were attacked. And this led to the first implementation of MixNets called MixMaster, an anonymous remailer, by Lance Cottrell, who I don't know what happened to him. I've heard various rumors. And Lynn Sassaman, who people think could have been Nakamoto. And effectively, you would send your messages through a series of computers and mix them up together. That kind of unlinked the messages. And this eventually led to Tor by Roger Dingledeen, whose talk you should all see, I think, on Thursday. And they basically said, well, you know, mix that to really slow. Can we build something faster that does web browsing but goes through multiple peer-to-peer relays? And that's the anonymous solution that most of us still use today. And I remember discussing with Roger once. He was like, ah, you know, this hidden services thing, what's it, could it be good for? And then, well, it was good for Wikileaks, right? So Wikileaks let, uh, Chelsea Manning, who, and, uh, folks like Edward Snowden, leak documents securely revealing the scope of the mass NSA surveillance and the failure of the Iraq war, so forth and so on. So WikiLeaks is effectively a Tor hidden service. And so it helped change the world in the war in Iraq. And the belief of Julian Assange was by releasing information into the world, people could decide what was true and what's false. And this would slowly eliminate the centralization of power and the conspiracy between the nation states to kind of maintain their domination. Now, the problem is, of course, the nation states weren't very happy with that. They obviously put Assange in jail. I just want to give a shout out to everyone who contributed to Assange Dow. I was good friends with Julian. And, you know, I said, Julian, don't you have tons of Bitcoin? He said, I sold it all to dollars. I was like, oh, Jesus, what a stupid thing to do. And then he was, like, kind of unsure about this ETH NFT stuff, but then it raised $16 million, if not more, to help him get out. Paid for his legal bills, and it's because of donations from everyone, particularly in Asia, that this happened. So that's absolutely wonderful, and it's a real use case of our technology. After WikiLeaks, there was, of course, the rise of Anonymous, which people may or may not remember from 2011. The first people that supported Arab Spring in Tunisia, of course, also came together because of Scientology. And some of you may not know this, and he may not be happy that I'm saying it, but Mustafa from Celestia, back in the day his name was T-Flow, and he was the youngest member of one of the kind of more prominent LulzSec anonymous crews. And even Vitalik himself was working at the kind of before Ethereum took off, he was living with Emir Taki and other people in Spain working on Dark Wallet, the first private kind of Bitcoin wallet, because it slowly occurred to people that Bitcoin wasn't private anonymous and we needed better technology, confidential transactions, so forth and so on. They did what was sort of the first, not ICO, but Bitcoin fundraise, and now Dark Wallet and all the cool stuff before it like Faircoin and Unsystem has evolved into Dark 5. I just want to give Rachel and Amir and everyone here shout outs and definitely come to Rachel's talk Lunar Punk Endgame to know what the future we're talking about the past but what the future of Cypherpunk holds and it will be on Wednesday at 4pm on stage 6. And at the same time as we're seeing this resurgence of the use of cryptography not to centralize power in the state but empower individuals through WikiLeaks and so forth and so on, anarchism itself is resurgent. There are now a large amount of interesting and wildly different anarchist books. I'm going to recommend a few here, but effectively they kind of argue that, you know, it's not just domination is not just a nation state, but domination is how we think of the world itself. That the world is not just something to be manipulated and controlled to satisfy our desires, but the world itself should be autonomous and free and This is there's also some newer questions in this book I would recommend there's the invisible committee and the tycoon a French collective of a book in 99 called the cybernetic Hypothesis and in this book they said capitalism based on the individual in a nation state is dying but actually it's being replaced by something worse a control society where computers are used to control and manipulate our behaviors and to make us completely transparent to various forms of power and domination but now the domination is not centralized in the palace, centralized in the king, but spread out and diffused through all society. And so I would just want to kind of end by discussing a little bit. We've covered a lot of history, and hopefully you got some cool screenshots of it, but what is actually the philosophy of cypherpunk? And I think it's actually a descendant of the philosophy of anarchism, which remember, happened at the same time the nation state itself started forming. And it's just the critique of anarchism, but given technological power through cryptography, which is ultimately a non-violent way to redistribute power relationships away from centralized power into individuals and smaller collectives, whatever they may be, communes, daos, so forth and so on. So the decentralization of power is the movement of sovereignty away from the nation state into the individual, and importantly, unlike all the rabid nonsense going on in politics today, it's universal to all humans, that we believe that all humans have the right to use strong cryptography, the right to transact freely, and to have freedom of speech. And that's like the fundamental, you can see how blockchain technology enables that. And also it's important that we, you know, we talk a lot about DAOs, but the fundamental structure is more deep. Voluntary association. That via contracts and market structures, we can create a society without domination and exploitation. By any form of ruling class or other kind of terrible self-inflicted domination. And then furthermore, that information itself, and this is where cryptography comes in quite useful, should be based on strong anonymity. You should be anonymous, first and foremost. And then you should, as Eric Hughes in the Cypherpunk Manifesto stated, which we kind of skipped over, but it's an excellent small text, I recommend reading it, that the real power of cryptography comes from the ability to selectively disclose yourself to the world. So you don't have a single identity. You can be a different person in different social spaces, at different points in your life, and amongst different crowds. And cryptography enables that universally using the internet. And this gives us agency over our flows of data, which more and more compose who we are. And the cypherpunk tech is still under development. Again, we have mixed nets. There's quite a few teams working on them. We at NIM are also working on one. Electronic cache, which, you know, of course, you have Zcache and Monero. But we decentralized fast private e-cash is still not a solved problem. And I think this has been incredibly neglected. We need anonymous credentials. We need ability to selectively disclose, I think ZK Passport and some other teams and Rarimo or whatever are working on this, the ability to selectively disclose arbitrary characteristics about ourselves but generalizable. We're also working on that a bit. And I guess the question we have is what are the consequences for Ethereum? Right? So we have, again, there are two paths of technology, as I think Amir Taki has said, looking at Lewis Mumford. And one path, we have the centralization of mega-machinic technology which sucks power away from the individual and two centralized power structures making us all slaves to the machine. And I think in the worst possible world, blockchain technology would make this worse, that we would be completely enslaved in some sort of libertarian nightmare where our movements and everything we do and our transactions are transparent to everyone and recorded. But the cypherpunk saying is transparency for the powerful, privacy for the weak. So we should have not identities, not soulbound tokens, not complete nonsense like dids or various authoritarian technology claiming to be self-sovereign like this self-sovereign identity nonsense but we should instead support zero knowledge proofs anonymous credentials that enable selective disclosure okay yeah i really wish people just not put the word self-sovereign in front of fascist technology and be like oh it makes it all better. It's so stupid. Privacy on chain is not succinctness. Everyone in Ethereum is obsessed with gas fees and making things succinct. But reality is we need private smart contracts, which DarkFi and Alejo and other folks are working on, private transactions, Aztec and Tornado Cash. And again, remember, we have to support our political prisoners Roman storm cement off and Alex support them and I'll just try to ending right now but we also we're now discussion of adding someone in the last session said what when should we add privacy to the network in aetherium I would say what better time than now and what better people than you all out there. We have mixed nets and NPC solutions which can help with network privacy and help with inclusion lists to make you know Ethereum not a censorship chain but a real chain open to the whole world and we need to defend validators from each other to prevent DDoS attacks and clients from malicious RPC nodes. And again, let's not forget another political prisoner who was the only person to support mixed nets when we started, but now is in jail or almost out, Virgil Griffith. So that's it. Yeah, that's it. Whoa. All right. You know If everyone had that level of passion I think we could change the world tomorrow But nevertheless Thank you For that very passionate speech And I believe privacy is an important thing Freedom is an important thing But let's go over to the Q&A section And we've got some interesting questions The top voted question, quite fun. Why does cypherpunk sound so religious? Would a religious fervor lead to cypherpunk being not that different from the future? It replaces. Very philosophical question. Some deep ideas there. How would you like to address this? Well, I would say religions generally start as movements against corruption and centralization wow i mean they do and then what happens is they're then incorporated into the nation state so for example buddhism i apologize i don't know too much about but like with christianity you have you know jesus throwing the people out the temple and then all of a sudden becoming merging with the roman empire right people do cypherpunk sounds religious because it's fundamentally an ethical and moral movement. That level is similar to religion, but rather than promising a pie in the sky, a happy afterlife, we want to create a better society now. And that will lead to passion. I would rather have people be passionate about building a better society now, right now, with the tools we have, than believe in something else. Well said. You want to add on? Yeah, if I could just add something as well. I mean, we've also been talking about, like, anarchy and a lot of anarchist political philosophy as well, which truly, I mean, all of that not solely relies on but is fully undergirded by the passion of believing in each other as human beings as well. So there's a crossover there with, let's say, like religious fervor, as you said in the question, but I think you can still distinguish those two things in a meaningful enough way, and it's still positive. Very much so. Thank you for answering that. Now, funny question at the top. Trump pumping our bags is good for funding cypherpunk's tech research. Cypherpunk. Cypherpunk. I'm just kidding. I mean, I would argue, look, more capital has been wasted in the pumping of bags than I've seen before. And there's a double side to the blockchain technology. All the interesting creative concepts come, at least from my perspective, from the cypherpunk movements. Blockchain, smart contracts, digital cash, anonymous cash. And then you have all this kind of, you know, other stuff coming from more traditional financial institutions, taking financial techniques. And, you know, I'm not against it, letting them be more widely accessible. And I would argue that what you're seeing now is you're seeing the movement, particularly with ETFs and what I was being, slowly more and more moving away from cypherpunk ideals and more towards just traditional financial pump-and-dump scams like whatever Trump is doing with DeFi, World Liberty, blah, blah. And so it's true that some percentage of that money is being spent for cypherpunk tooling, but very little, almost none. Tor Project, which has been providing anonymity for decades, their founder is here, Roger Dingledeen, but they don't have enough money. Very few people have donated Ethereum. So we have some good uses, like AssangeDAO, but most cypherpunk tech is incredibly underfunded. And now because of privacy, blah, blah, blah, and turn their cash, people are afraid of touching it and funding it. I know I raised money from A16 and whatnot. Some people throw down, but it's increasingly hard. Also, just be realistic with what amount of bandwidth you actually have when you're building. If you're optimizing for something to pump a bag, then you will build something that pumps a bag. That is it. So you also need to think about the amount of innovation tokens you have to spend on any of these projects, even though in theory, yeah, you could have your bags pumped by a bad thing happening. And just quickly, centralized power in general does not empower people. And cypherpunk is about empowering people, so that's why we push for decentralization. Voluntary associations do not necessarily evolve into nation states. Historically, they actually destroyed nation states from barbarians sacking Rome onwards. And I think that's not necessary. And I do recommend that people just basically throw down as much as they can on this tech yeah this is decentralization thanks everyone ladies and gentlemen fight against the mc and the mc state ladies and gentlemen let's give our two speakers a big big",
"eventId": "devcon-7",
- "slot_start": 1731492000000,
- "slot_end": 1731493800000,
+ "slot_start": 1731407400000,
+ "slot_end": 1731409200000,
"slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1j5n0blTsDLltg5bxumMOQ0zvAqbfL-faBMhuzsnBX3k",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ovH3oyNrS_ZaZbKCeLkHxgPjrRCAzaWP7RVIf9TRkOo",
"resources_slides": null,
"speakers": [
- "ed-felten"
+ "max-hampshire",
+ "harry-halpin",
+ "iness-ben-guirat"
]
},
"vector": [
@@ -744989,8 +743408,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -745348,6 +743765,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -745627,6 +744045,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -745759,6 +744178,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -745781,6 +744202,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -745802,7 +744224,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -745855,6 +744276,9 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
0,
0,
0,
@@ -746062,6 +744486,15 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -746100,6 +744533,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -746221,6 +744656,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -746241,25 +744678,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -746304,14 +744722,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0
@@ -746319,30 +744735,40 @@
},
{
"session": {
- "id": "the-future-of-light-clients",
- "sourceId": "UL8U8B",
- "title": "The Future of Light Clients",
- "description": "Ethereum has achieved a remarkable feat: production-ready light clients. There are now at least seven light client projects active on Ethereum today.\r\n\r\nHowever, light clients have kept up with Ethereum’s future, Layer 2s. Implementations for layer 2s have been mostly overlooked. This is due to both the low prioritization of work on light clients and significant technical challenges. In this talk, we will discuss the path to layer 2 light clients and our work to bring them to production in Helios.",
- "track": "Layer 2",
+ "id": "the-hunt-for-impactful-use-cases-from-the-crypto-for-good-fund-what-15-blockchain-pilots-revealed-in-emerging-markets",
+ "sourceId": "TV3QRD",
+ "title": "The Hunt for Impactful Use Cases from the Crypto For Good Fund: What 15 Blockchain Pilots Revealed in Emerging Markets",
+ "description": "* This talk will provide a snapshot of the some of most impactful real world uses of web3 in emerging markets covering the additionality added by blockchain. \r\n* Additionally, the talk will deep-dive into the insights and results of 3 web3 pilots funded by Mercy Corps Ventures in Africa & Latin America, showcasing how web3 is addressing the needs of financially underserved and climate vulnerable populations.",
+ "track": "Real World Ethereum",
"type": "Talk",
- "expertise": "Expert",
- "audience": "Research",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [],
+ "keywords": [
+ "Emerging Markets",
+ "Africa",
+ "Latin America"
+ ],
"tags": [
- "Layer 2s",
- "Light Clients"
+ "Use Cases",
+ "RWA",
+ "Ethereum for Good",
+ "latin",
+ "america",
+ "Ethereum for Good",
+ "RWA",
+ "Use Cases"
],
"language": "en",
"speakers": [
- "noah-citron"
+ "timothy-asiimwe"
],
"eventId": "devcon-7",
- "slot_start": 1731493800000,
- "slot_end": 1731495600000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/11L_sO6Usnx1os7aiKFPC2mNm1diDnV9Hlo7PETnsic8"
+ "slot_start": 1731641400000,
+ "slot_end": 1731643200000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1vwkrczNxrHXLNfycNjtYzjJo4jXX3Z2RUJ7NWPh4OMQ"
},
"vector": [
0,
@@ -746351,7 +744777,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -746988,10 +745413,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -747117,7 +745540,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -747163,7 +745585,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -747178,6 +745599,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -747224,6 +745646,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -747251,6 +745674,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -747602,6 +746026,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -747657,11 +746083,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
- 2,
0,
2,
0,
@@ -747672,43 +746098,45 @@
0,
0,
0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "the-future-of-web3-grants-learnings-from-studying-30-programs",
- "sourceId": "F9YCZY",
- "title": "The Future of Web3 Grants: Learnings from Studying 30+ Programs",
- "description": "This presentation will cover learnings from studying almost 3 dozen grant programs across multiple chains and ecosystems. I will present an overview of the state of grants across Ethereum as well as Bitcoin, Cardano, Solana, and other chains. I will present on the most pressing challenges for grant operators, feedback from grantees on their experiences, and will present a potential path forward in terms of collective priorities that can help all programs improve.",
- "track": "Coordination",
- "type": "Lightning Talk",
+ "id": "the-long-con-pig-butchering-drainers-and-job-scams",
+ "sourceId": "STMCNZ",
+ "title": "The Long Con: Pig Butchering, Drainers, and Job Scams",
+ "description": "I'll discuss the different types of malicious actors from low-skilled script kiddies to government-sanctioned advanced persistent threats. This presentation will include an overview on drainer groups and how sophisticated scammers string along their victims, fattening them up before extracting as much value as they can, as well as the nefarious practices these operations employ. Finally, I'll focus on the recent rise of job scams that have been targeting builders and employers alike.",
+ "track": "Security",
+ "type": "Talk",
"expertise": "Beginner",
"audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Grant",
- "Allocation",
- "Capital"
+ "threat",
+ "intelligence"
],
"tags": [
- "capital"
+ "Security",
+ "Custody",
+ "threat",
+ "intelligence",
+ "Custody",
+ "Security"
],
"language": "en",
"speakers": [
- "eugene-leventhal"
+ "luker"
],
"eventId": "devcon-7",
- "slot_start": 1731641400000,
- "slot_end": 1731642000000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1kRi6qfFHeK8txYMq58KLUaOTV4stHccKNP0m-WyZWWg"
+ "slot_start": 1731582000000,
+ "slot_end": 1731583800000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1dFgaih8CwwDPKj_GGRG-nwZ_b7MobKt9l-QDbYxwOPk"
},
"vector": [
+ 6,
0,
0,
0,
@@ -747720,7 +746148,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -748458,6 +746885,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -748709,6 +747137,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -748931,6 +747361,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -748967,13 +747398,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -749044,60 +747468,41 @@
},
{
"session": {
- "id": "the-history-and-philosophy-of-cypherpunk",
- "sourceId": "8JVYCQ",
- "title": "The History and Philosophy of Cypherpunk",
- "description": "Rather than bend to knee to Donald Trump, the goal of the cypherpunk movement is to abolish the state in order to maximize human freedom via privacy-enhancing decentralized technologie. After reviewing the history of this deviant group of programmers in the 1980s, what philosophical and technical lessons do the cypherpunks hold for Ethereum today? Censorship-resistant digital cash was only one the start, and the missing parts of their legacy: mixnets and anonymous credentials for identity.",
- "track": "Cypherpunk & Privacy",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "the-longevity-acceleration-roadmap-a-technical-plan-to-solve-aging",
+ "sourceId": "V9BA8B",
+ "title": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging",
+ "description": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Anonymity",
- "Censorship Resistance",
- "Digital Sovereignty",
- "cypherpunk",
- "mixnet",
- "cryptoanarchy",
- "Anonymity",
- "Politics",
- "Values"
- ],
"keywords": [
- "mixnets",
- "cypherpunk",
- "cryptoanarchist"
+ "Longevity"
+ ],
+ "tags": [
+ "DeSci",
+ "e/acc"
],
- "duration": 1555,
"language": "en",
- "sources_swarmHash": "89ddf65d60e9d080ec70f2820e3674c757d151a0741047ec721bd81ba034a27e",
- "sources_youtubeId": "prXQJSp_H8A",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673351433a168eb5355b5f3c.vtt",
- "transcript_text": " Okay, so we are here to basically bring back the cypherpunk roots of blockchain technology. I'm Harry, CEO of NIM. And I'm Max, Senior DevRel for NIMH. So also if you want to talk about building anything with NIMH, come find me over the rest of the conference. So I would just like to begin this talk saying that I'm actually very proud of Vitalik in the blog post where he decided he was not going to bend the knee to Donald Trump just because Donald Trump was going to pump everyone's crypto bags. Donald Trump and authoritarian states are the opposite of cypherpunk. It's the opposite of our ethos. The ethos of cypherpunk is based on meritocracy without borders, right? Not nationalism, not kicking out immigrants and all sorts of other complete nonsense. So I think it is a good time to kind of go into the history of how cypherpunk came to be. And we're going to do it a little bit differently. I've seen a lot of talks about, you know, Phil Zimmerman and Eric Hughes and the original cypherpunk movement, but there's a lot of stuff left out. So that's what we're going to go through. I'd like to just give a shout-out to the father, the inventor of the term anarchism, Pierre Proudhon, who had, at the dawn of the Industrial Revolution, many core concepts that now we are only seeing come to fruition. For example, do you know in 1863, Pierre said we can replace the monarchy with self-governing communes and collectives and individuals who will coordinate via contracts and create their own popular banking systems. Of course, he was taken out by Marx, and generally, kind of no one looks at him academically anymore, but there's really old roots. And then a lot of the questions that we are facing today came forward in what's called the socialist calculation debate, where the question was, how is it that we can reorganize society? Should we use money or not? Should we plan in a centralized way or not? And most of Austrian economics, Hayek and Van Mises and all these folks came from this debate as a reaction against the socialists from Vienna like Otto von Neurath who claimed that money does not capture all the externalities in the well-being of population. So it's a really old history that predates cryptography and the invention of computing about these topics. Should we organize in a decentralized way, returning sovereignty and power to individuals and to smaller communities or should we centralize power? If you're interested in more tons of philosophy work here, but the general thesis is that the spread of cryptographic techniques, which were originally the domain of the nation state, because the nation state is based on hierarchies, on the keeping of secrets, keeping of secrets around agriculture, keeping of secrets around military, cryptography let this spread into the general population, and this has been perhaps the most defying change in sovereignty since like essentially ancient sumer go for it max all right so this section of the talk we're going to go through a couple of let's say the more basic like um technological advances that have happened and then i'm going gonna then, these are things that we imagine that kind of everyone here knows about, but we'll do a quick overview and then we'll really jump into the more like the social side of cypherpunk and how this is, how it feeds back into the technology it creates. So in 67, Whitfield, Diffie and Martin Hellman, they kind of introduced public key cryptography into the public domain right so it's just the idea that you can for the first time then you could create a shared secret key with which you could have like secret communication uh over a non-confidential channel beforehand one of the massive problems of actually like setting up any kind of encrypted comms with people was how do you initially share this secret between both of you right this is the public key cryptography as well as being the basis of like tls ssl it's also obviously like the basis of so much of the crypto that we use today uh can we do the next slide all right so then in 79 david charm invented mixnets with untraceable electronic mail return addresses and digital pseudonyms right the t TLDR of this is how do you create an anonymous, untraceable communication network that protects the data of your comms, right? As well as the metadata. So can you create something wherein you can't tell who is talking to who and when? Next one. There we go. And not too long afterwards afterwards he then came out with another concept which is that of anonymous credentials to defend against a dossier society so this first line of this paper from 1985 I think sums it up better than a lot of stuff still sums it up today so computerization is robbing individuals of the ability to monitor and control the ways that information about them is used. So in 85, Charm was already talking about the lack of agency that people were having with regards to the data that was about themselves and how they communicate in the world and could already see the kind of possible dystopia on the horizon. So finally, we had Diffie-Hellman. They allowed people to create, to envisage stuff like Miss Next, which allow you to communicate privately. And then also we have credentials, which allow you to transact privately. These two kind of key cornerstones of like cypherpunk tech that then can be used to envision this kind of better society that we're talking about here. So that was the stuff that I kind of imagined everyone would already know. Now we'll go on to the more fun stuff. So this was Resource One's project, Community Memory. This was the first computerized public bulletin board system. So the first introduction that a lot of people would have had to computing in general uh it was in the people's computing center in san francisco and it was the yeah like i said the first pbs so the first way that people were able to like freely share and spread information using computer systems this is interesting because one of the people who is criminally under talked about in this space uh was also key in not just resource one but also the creation of the people's computing center and that's Jude Milhoon so otherwise known as Saint Jude she was actually the originator of the term cypherpunk itself so the title of this Congress and everything else owes that to her and as well as being a founding member of the Cypherpunks mailing list, she was a civil rights activist. So actually this picture from the Montgomery Police Department is after she got arrested in Montgomery, Alberta, on a civil rights march in 67. And it was broad civil rights activism throughout her entire life. She was also a senior editor of Mondo 2000, which is now Wired, so you can see how both tech and culture is constantly feedbacking, the feedback cycle is tight, basically. And a couple of choice quotes of, hacking is a martial art, a way of defending against politically correct politicians, overly intrusive laws, bigots, and narrow-minded people of all persuasions. These are some of her publications take a picture they're all really fun and good but we don't have that much time and a lot to get through so another piece of culture that fed back into the early cypherpunk movement and became part of as well its true names by Verna Vinger this is a novel which actually has the original use of the word nim in terms of pseudonym or hidden name and was even though it was written in a1 thoroughly predictive of government surveillance of parallel online spaces this then fed into one of the kind of like the author of a series of seminal texts within this, right, which is Tim May. So not only just True Names and Crypto Anarchy, which was an essay that then actually Vinger enjoyed so much, it was included in the late 90s represses of True Names. He was a founding member of the Cypherpunks mailing list, and his, let's say, predictive power to understand both the potential of this tech, so providing the ability for individuals and groups to communicate and interact with each other in a totally anonymous manner is something to bring attention to. Finally, a lesser known, let's say, strain of thought that I think is still foundational to a lot of the cypherpunk ethos that we want to push forward today is that of agorism. So agorism, until fairly recently, when it was revitalized by the Agorist Journal. So check that out at agorism.xyz. Then this was a relatively little-known strain of political political thought but still had a massive impact on the cypherpunk culture this is the idea of a counter economy right so possibly a different way of thinking about what we would maybe call parallel societies or these kind of like non-state these non-state market structures right so his was very much based in anti-statism and kind of went all the way from black markets to gray markets to just unregulated people helping each other out and the novel that's included here alongside night is you could almost think of it as kind of a dramatized thought experiment of a young man who as society is kind of crumbling down, his kind of journey through the agorist underworld to regain, I suppose, freedom in the way that Konkin described it. And I'll kick it back to Harry now. So where things all started getting real for the cypherpunks, it was interesting concepts and everyone here is inheriting this tradition. It was actually, hilariously enough, as the early internet took off, people leaked the secret beliefs of the Church of Scientology, who you may know as a lot of lawyers. And they started trying to go after some of the cypherpunks and crypto-anarchists. And this led to the invention of what was called the Cypherpunk Anonymous Remailer. So you took emails, put them in PGP, sent them to the computer, stripped off the header and sent them out. However, unfortunately, those Cypherpunk remailers were attacked. And this led to the first implementation of MixNets called MixMaster, an anonymous remailer, by Lance Cottrell, who I don't know what happened to him. I've heard various rumors. And Lynn Sassaman, who people think could have been Nakamoto. And effectively, you would send your messages through a series of computers and mix them up together. That kind of unlinked the messages. And this eventually led to Tor by Roger Dingledeen, whose talk you should all see, I think, on Thursday. And they basically said, well, you know, mix that to really slow. Can we build something faster that does web browsing but goes through multiple peer-to-peer relays? And that's the anonymous solution that most of us still use today. And I remember discussing with Roger once. He was like, ah, you know, this hidden services thing, what's it, could it be good for? And then, well, it was good for Wikileaks, right? So Wikileaks let, uh, Chelsea Manning, who, and, uh, folks like Edward Snowden, leak documents securely revealing the scope of the mass NSA surveillance and the failure of the Iraq war, so forth and so on. So WikiLeaks is effectively a Tor hidden service. And so it helped change the world in the war in Iraq. And the belief of Julian Assange was by releasing information into the world, people could decide what was true and what's false. And this would slowly eliminate the centralization of power and the conspiracy between the nation states to kind of maintain their domination. Now, the problem is, of course, the nation states weren't very happy with that. They obviously put Assange in jail. I just want to give a shout out to everyone who contributed to Assange Dow. I was good friends with Julian. And, you know, I said, Julian, don't you have tons of Bitcoin? He said, I sold it all to dollars. I was like, oh, Jesus, what a stupid thing to do. And then he was, like, kind of unsure about this ETH NFT stuff, but then it raised $16 million, if not more, to help him get out. Paid for his legal bills, and it's because of donations from everyone, particularly in Asia, that this happened. So that's absolutely wonderful, and it's a real use case of our technology. After WikiLeaks, there was, of course, the rise of Anonymous, which people may or may not remember from 2011. The first people that supported Arab Spring in Tunisia, of course, also came together because of Scientology. And some of you may not know this, and he may not be happy that I'm saying it, but Mustafa from Celestia, back in the day his name was T-Flow, and he was the youngest member of one of the kind of more prominent LulzSec anonymous crews. And even Vitalik himself was working at the kind of before Ethereum took off, he was living with Emir Taki and other people in Spain working on Dark Wallet, the first private kind of Bitcoin wallet, because it slowly occurred to people that Bitcoin wasn't private anonymous and we needed better technology, confidential transactions, so forth and so on. They did what was sort of the first, not ICO, but Bitcoin fundraise, and now Dark Wallet and all the cool stuff before it like Faircoin and Unsystem has evolved into Dark 5. I just want to give Rachel and Amir and everyone here shout outs and definitely come to Rachel's talk Lunar Punk Endgame to know what the future we're talking about the past but what the future of Cypherpunk holds and it will be on Wednesday at 4pm on stage 6. And at the same time as we're seeing this resurgence of the use of cryptography not to centralize power in the state but empower individuals through WikiLeaks and so forth and so on, anarchism itself is resurgent. There are now a large amount of interesting and wildly different anarchist books. I'm going to recommend a few here, but effectively they kind of argue that, you know, it's not just domination is not just a nation state, but domination is how we think of the world itself. That the world is not just something to be manipulated and controlled to satisfy our desires, but the world itself should be autonomous and free and This is there's also some newer questions in this book I would recommend there's the invisible committee and the tycoon a French collective of a book in 99 called the cybernetic Hypothesis and in this book they said capitalism based on the individual in a nation state is dying but actually it's being replaced by something worse a control society where computers are used to control and manipulate our behaviors and to make us completely transparent to various forms of power and domination but now the domination is not centralized in the palace, centralized in the king, but spread out and diffused through all society. And so I would just want to kind of end by discussing a little bit. We've covered a lot of history, and hopefully you got some cool screenshots of it, but what is actually the philosophy of cypherpunk? And I think it's actually a descendant of the philosophy of anarchism, which remember, happened at the same time the nation state itself started forming. And it's just the critique of anarchism, but given technological power through cryptography, which is ultimately a non-violent way to redistribute power relationships away from centralized power into individuals and smaller collectives, whatever they may be, communes, daos, so forth and so on. So the decentralization of power is the movement of sovereignty away from the nation state into the individual, and importantly, unlike all the rabid nonsense going on in politics today, it's universal to all humans, that we believe that all humans have the right to use strong cryptography, the right to transact freely, and to have freedom of speech. And that's like the fundamental, you can see how blockchain technology enables that. And also it's important that we, you know, we talk a lot about DAOs, but the fundamental structure is more deep. Voluntary association. That via contracts and market structures, we can create a society without domination and exploitation. By any form of ruling class or other kind of terrible self-inflicted domination. And then furthermore, that information itself, and this is where cryptography comes in quite useful, should be based on strong anonymity. You should be anonymous, first and foremost. And then you should, as Eric Hughes in the Cypherpunk Manifesto stated, which we kind of skipped over, but it's an excellent small text, I recommend reading it, that the real power of cryptography comes from the ability to selectively disclose yourself to the world. So you don't have a single identity. You can be a different person in different social spaces, at different points in your life, and amongst different crowds. And cryptography enables that universally using the internet. And this gives us agency over our flows of data, which more and more compose who we are. And the cypherpunk tech is still under development. Again, we have mixed nets. There's quite a few teams working on them. We at NIM are also working on one. Electronic cache, which, you know, of course, you have Zcache and Monero. But we decentralized fast private e-cash is still not a solved problem. And I think this has been incredibly neglected. We need anonymous credentials. We need ability to selectively disclose, I think ZK Passport and some other teams and Rarimo or whatever are working on this, the ability to selectively disclose arbitrary characteristics about ourselves but generalizable. We're also working on that a bit. And I guess the question we have is what are the consequences for Ethereum? Right? So we have, again, there are two paths of technology, as I think Amir Taki has said, looking at Lewis Mumford. And one path, we have the centralization of mega-machinic technology which sucks power away from the individual and two centralized power structures making us all slaves to the machine. And I think in the worst possible world, blockchain technology would make this worse, that we would be completely enslaved in some sort of libertarian nightmare where our movements and everything we do and our transactions are transparent to everyone and recorded. But the cypherpunk saying is transparency for the powerful, privacy for the weak. So we should have not identities, not soulbound tokens, not complete nonsense like dids or various authoritarian technology claiming to be self-sovereign like this self-sovereign identity nonsense but we should instead support zero knowledge proofs anonymous credentials that enable selective disclosure okay yeah i really wish people just not put the word self-sovereign in front of fascist technology and be like oh it makes it all better. It's so stupid. Privacy on chain is not succinctness. Everyone in Ethereum is obsessed with gas fees and making things succinct. But reality is we need private smart contracts, which DarkFi and Alejo and other folks are working on, private transactions, Aztec and Tornado Cash. And again, remember, we have to support our political prisoners Roman storm cement off and Alex support them and I'll just try to ending right now but we also we're now discussion of adding someone in the last session said what when should we add privacy to the network in aetherium I would say what better time than now and what better people than you all out there. We have mixed nets and NPC solutions which can help with network privacy and help with inclusion lists to make you know Ethereum not a censorship chain but a real chain open to the whole world and we need to defend validators from each other to prevent DDoS attacks and clients from malicious RPC nodes. And again, let's not forget another political prisoner who was the only person to support mixed nets when we started, but now is in jail or almost out, Virgil Griffith. So that's it. Yeah, that's it. Whoa. All right. You know If everyone had that level of passion I think we could change the world tomorrow But nevertheless Thank you For that very passionate speech And I believe privacy is an important thing Freedom is an important thing But let's go over to the Q&A section And we've got some interesting questions The top voted question, quite fun. Why does cypherpunk sound so religious? Would a religious fervor lead to cypherpunk being not that different from the future? It replaces. Very philosophical question. Some deep ideas there. How would you like to address this? Well, I would say religions generally start as movements against corruption and centralization wow i mean they do and then what happens is they're then incorporated into the nation state so for example buddhism i apologize i don't know too much about but like with christianity you have you know jesus throwing the people out the temple and then all of a sudden becoming merging with the roman empire right people do cypherpunk sounds religious because it's fundamentally an ethical and moral movement. That level is similar to religion, but rather than promising a pie in the sky, a happy afterlife, we want to create a better society now. And that will lead to passion. I would rather have people be passionate about building a better society now, right now, with the tools we have, than believe in something else. Well said. You want to add on? Yeah, if I could just add something as well. I mean, we've also been talking about, like, anarchy and a lot of anarchist political philosophy as well, which truly, I mean, all of that not solely relies on but is fully undergirded by the passion of believing in each other as human beings as well. So there's a crossover there with, let's say, like religious fervor, as you said in the question, but I think you can still distinguish those two things in a meaningful enough way, and it's still positive. Very much so. Thank you for answering that. Now, funny question at the top. Trump pumping our bags is good for funding cypherpunk's tech research. Cypherpunk. Cypherpunk. I'm just kidding. I mean, I would argue, look, more capital has been wasted in the pumping of bags than I've seen before. And there's a double side to the blockchain technology. All the interesting creative concepts come, at least from my perspective, from the cypherpunk movements. Blockchain, smart contracts, digital cash, anonymous cash. And then you have all this kind of, you know, other stuff coming from more traditional financial institutions, taking financial techniques. And, you know, I'm not against it, letting them be more widely accessible. And I would argue that what you're seeing now is you're seeing the movement, particularly with ETFs and what I was being, slowly more and more moving away from cypherpunk ideals and more towards just traditional financial pump-and-dump scams like whatever Trump is doing with DeFi, World Liberty, blah, blah. And so it's true that some percentage of that money is being spent for cypherpunk tooling, but very little, almost none. Tor Project, which has been providing anonymity for decades, their founder is here, Roger Dingledeen, but they don't have enough money. Very few people have donated Ethereum. So we have some good uses, like AssangeDAO, but most cypherpunk tech is incredibly underfunded. And now because of privacy, blah, blah, blah, and turn their cash, people are afraid of touching it and funding it. I know I raised money from A16 and whatnot. Some people throw down, but it's increasingly hard. Also, just be realistic with what amount of bandwidth you actually have when you're building. If you're optimizing for something to pump a bag, then you will build something that pumps a bag. That is it. So you also need to think about the amount of innovation tokens you have to spend on any of these projects, even though in theory, yeah, you could have your bags pumped by a bad thing happening. And just quickly, centralized power in general does not empower people. And cypherpunk is about empowering people, so that's why we push for decentralization. Voluntary associations do not necessarily evolve into nation states. Historically, they actually destroyed nation states from barbarians sacking Rome onwards. And I think that's not necessary. And I do recommend that people just basically throw down as much as they can on this tech yeah this is decentralization thanks everyone ladies and gentlemen fight against the mc and the mc state ladies and gentlemen let's give our two speakers a big big",
- "eventId": "devcon-7",
- "slot_start": 1731407400000,
- "slot_end": 1731409200000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1ovH3oyNrS_ZaZbKCeLkHxgPjrRCAzaWP7RVIf9TRkOo",
- "resources_slides": null,
"speakers": [
- "max-hampshire",
- "harry-halpin",
- "iness-ben-guirat"
- ]
+ "nathan-cheng"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731557580000,
+ "slot_end": 1731558000000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/160SSgpDZHkjg4YniAuH3mYD1hx7hZuv_Qp2ip0zoRso"
},
"vector": [
+ 0,
+ 6,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -749455,7 +747860,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -749737,7 +748141,6 @@
0,
0,
0,
- 6,
6,
0,
0,
@@ -749870,7 +748273,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -749894,7 +748296,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -749968,7 +748369,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -749979,6 +748379,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -749992,7 +748393,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -750001,6 +748401,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -750179,7 +748583,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -750226,7 +748629,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -750351,8 +748753,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -750410,11 +748810,12 @@
2,
0,
0,
+ 2,
+ 0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -750427,50 +748828,45 @@
},
{
"session": {
- "id": "the-hunt-for-impactful-use-cases-from-the-crypto-for-good-fund-what-15-blockchain-pilots-revealed-in-emerging-markets",
- "sourceId": "TV3QRD",
- "title": "The Hunt for Impactful Use Cases from the Crypto For Good Fund: What 15 Blockchain Pilots Revealed in Emerging Markets",
- "description": "* This talk will provide a snapshot of the some of most impactful real world uses of web3 in emerging markets covering the additionality added by blockchain. \r\n* Additionally, the talk will deep-dive into the insights and results of 3 web3 pilots funded by Mercy Corps Ventures in Africa & Latin America, showcasing how web3 is addressing the needs of financially underserved and climate vulnerable populations.",
- "track": "Real World Ethereum",
+ "id": "the-next-700-evm-languages",
+ "sourceId": "QE7RWH",
+ "title": "The Next 700 EVM Languages",
+ "description": "What is the role of programming languages in helping smart contracts become reliable and scalable technology? Are our current languages for the EVM up to the task? Has Ethereum lost the lead in this regard?\r\nThis talk explores these questions and proposes a roadmap for the development of the next generation of smart contract languages for the EVM.",
+ "track": "Developer Experience",
"type": "Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Emerging Markets",
- "Africa",
- "Latin America"
+ "programming languages",
+ "formal verification",
+ "smart contracts"
],
"tags": [
- "Use Cases",
- "RWA",
- "Ethereum for Good",
- "latin",
- "america",
- "Ethereum for Good",
- "RWA",
- "Use Cases"
+ "Languages",
+ "Formal Verification",
+ "smart",
+ "contracts"
],
"language": "en",
"speakers": [
- "timothy-asiimwe"
+ "francisco-giordano"
],
"eventId": "devcon-7",
- "slot_start": 1731641400000,
- "slot_end": 1731643200000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1vwkrczNxrHXLNfycNjtYzjJo4jXX3Z2RUJ7NWPh4OMQ"
+ "slot_start": 1731580200000,
+ "slot_end": 1731582000000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1xFEtAafqxxm1b1UAUHGb8bnoWg9x6qZQdGRk_3lPM8Y"
},
"vector": [
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -751294,7 +749690,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -751311,6 +749706,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -751341,7 +749737,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -751369,7 +749764,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -751412,6 +749806,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -751472,6 +749867,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -751724,8 +750121,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -751775,6 +750170,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -751784,8 +750180,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -751798,41 +750192,48 @@
},
{
"session": {
- "id": "the-long-con-pig-butchering-drainers-and-job-scams",
- "sourceId": "STMCNZ",
- "title": "The Long Con: Pig Butchering, Drainers, and Job Scams",
- "description": "I'll discuss the different types of malicious actors from low-skilled script kiddies to government-sanctioned advanced persistent threats. This presentation will include an overview on drainer groups and how sophisticated scammers string along their victims, fattening them up before extracting as much value as they can, as well as the nefarious practices these operations employ. Finally, I'll focus on the recent rise of job scams that have been targeting builders and employers alike.",
- "track": "Security",
+ "id": "the-next-era-sequencing-and-its-real-impact-on-app-users",
+ "sourceId": "9M78AK",
+ "title": "The Next Era: Sequencing and Its Real Impact on App Users",
+ "description": "This talk will discuss app sequencing products which were developed to enhance decentralization and security via distributed transaction ordering with independent sequencing (native Mainnet L2 sequencers i.e. Base, OP) and the impact to end users and applications. It will also discuss the tradeoffs of LVR, shared sequencing, and app-specific sequencing.",
+ "track": "Usability",
"type": "Talk",
- "expertise": "Beginner",
- "audience": "Community",
+ "expertise": "Intermediate",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "threat",
- "intelligence"
- ],
"tags": [
- "Security",
- "Custody",
- "threat",
- "intelligence",
- "Custody",
- "Security"
+ "Layer 2s",
+ "User Experience",
+ "Transaction fees mechanisms",
+ "sequencer",
+ "Layer 2s",
+ "Transaction fees mechanisms",
+ "User Experience"
],
- "language": "en",
- "speakers": [
- "luker"
+ "keywords": [
+ "Sequencing"
],
+ "duration": 975,
+ "language": "en",
+ "sources_swarmHash": "707cb042ec5704ebd467c773dedb087d6fc5a3c474c0c41441a2ed12ac9ec02d",
+ "sources_youtubeId": "-S2rlhSUHZY",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731582000000,
- "slot_end": 1731583800000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1dFgaih8CwwDPKj_GGRG-nwZ_b7MobKt9l-QDbYxwOPk"
+ "slot_start": 1731405600000,
+ "slot_end": 1731407400000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1l63vZZz_0RN-aU0hwjhmdAat5Fq0OFy7UoMYiS3KJxc",
+ "resources_slides": null,
+ "speakers": [
+ "tina-haibodi"
+ ]
},
"vector": [
- 6,
- 0,
0,
0,
0,
@@ -751841,6 +750242,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -752583,11 +750985,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -752602,6 +750999,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -752625,6 +751023,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -752650,6 +751049,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -752695,6 +751095,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -752836,8 +751237,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -753062,7 +751461,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -753153,6 +751551,7 @@
0,
0,
0,
+ 0,
2,
0,
0,
@@ -753161,41 +751560,47 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "the-longevity-acceleration-roadmap-a-technical-plan-to-solve-aging",
- "sourceId": "V9BA8B",
- "title": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging",
- "description": "The Longevity Acceleration Roadmap: A Technical Plan to Solve Aging",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "",
- "audience": "Engineering",
+ "id": "the-next-generation-of-decentralized-governance",
+ "sourceId": "WUSAHA",
+ "title": "The Next Generation of Decentralized Governance",
+ "description": "In this talk, tracheoptryx will share thoughts on what will define the next phase of decentralized governance and how that has informed the design of EigenGov, EigenLayer’s forthcoming governance system.",
+ "track": "Coordination",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
+ "tags": [],
"keywords": [
- "Longevity"
- ],
- "tags": [
- "DeSci",
- "e/acc"
+ "see",
+ "doc"
],
+ "duration": 1629,
"language": "en",
- "speakers": [
- "nathan-cheng"
- ],
+ "sources_swarmHash": "75a12cae9fadbaeaba434231a49a634d15b4251288154859b4667cd19622b603",
+ "sources_youtubeId": "VhkP2OIwIFY",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333c273a168eb535f16a85.vtt",
+ "transcript_text": " All right, so yeah, I'm really happy to be here. Take a moment to just enjoy that for a second. Hey, everyone. So I'm going to be speaking about decentralized governance today. I'm Trey Kioptririx. I'm a dinosaur. I am the chief governance officer at EigenLayer, or at the Eigen Foundation. That's where I'm working. Previously, I worked at, I was a contributor to Yearn Finance, where the gentleman who's leaving right now spoke before Gabe Shapiro and I both designed a governance system called Constrained Delegation, which informs a lot of the work that you just saw in Borgs and also what we're building at Eigenlayer. I also was a co-founder of Coordinate, which is a system for decentralized compensation. So I want to start, why does it even matter? Why do we need decentralized governance? Why is it important? I think we talk a lot about governance minimization, which is really important. If you can minimize it, do. But there's no way to minimize things at the frontier. You can't reduce the most new, confusing, misunderstood things into immutable code. There are periods where human beings have to come together in subjective reality and reason things out and make decisions together. We need some form of collective decision making, and we always will. And the forms that we have now and have for centuries aren't so great. They lead to wars and various other things. So beyond just the ability to launch a token and not get sued, decentralized governance has the potential to do much, much more. It has the potential to give us ways to not stop killing each other, for instance, which we haven't figured out as a species. It's a tall order, and there's a lot to do to get there, obviously. But, you know, here we have three predators that are already doing it. So we're going to take our cues from them. I want to talk a little bit about what DAOs are doing now before we talk about the future of decentralized governance. So today, DAOs are really good things, like increased transparency in organizations. Beautiful. More permissionless access to information and control. Capture resistance. more permissionless access to information and control capture resistance all these on-chain technologies allow for much greater security and to reduce capture by small groups give more access to people and they allow for decentralized decision-making which has been an incredible advance over the past you years, eight years. But it's not all happy stories, right? There's a sad dog as well. For instance, DAOs are pretty bad at power concentration. If you look at a lot of what seem like decentralized DAOs, you find that under the hood, they're maybe not so decentralized. They're also bad at skill-task matching, which is something we'll talk about a little bit more. There's tons of principal agent problems all throughout DAOs and low accountability. And while they're doing decentralized decision making, I'd argue that it's pretty ineffective low quality decision making in most cases. So what's the next generation? So far we've done well at decentralizing. But what's next? And it's pretty simple. It's making them decentralized and effective, which we don't really have any examples of today. But we're getting there. And so that's what we're working on at EigenLayer. So EigenLayer, we're doing Ethereum restaking, helping create a new ecosystem of AVSs and taking things off-chain, putting them on-chain on Ethereum to expand what's possible. This is a big, ambitious vision. It's a big, open ecosystem that we're building, and we need effective and decentralized governance. We need the people building on EigenLayer to have control and ownership over what happens on the commons that we're creating together. And it has to be, you know, for now, it's a tricky question. Decentralized or effective, right? You can kind of choose one. We don't have the technologies to do both yet. So in the beginning, it's kind of okay to be a little bit more centralized. And if Lefteris is out there, we're not a DAO yet, right? We're trying, but we're not yet. We're starting more centralized, and we're going to decentralize over time. And that's because we're focusing on quality decision-making. We're not going to give that up, and we believe that we can do both. But later, over time, it really does have to be centralized because you can only trust, you know, in the beginning the participants in the ecosystem need to know that Eigen layer is making good decisions, right? But over time after the, you know, honeymoon period is worn off, you need to trust that they're not going to screw you. And that needs to be decentralized. So we have this process we call incubation, which is our version of progressive decentralization. And in progressive decentralization usually, you know, you have a foundation which has the power, and it controls everything, and then it gives a chunk of power to a DAO, and then another chunk of power to the DAO. It's good. We're adding more gradation to this. So our version of this incubation, we take decentralized structures, and we operate them in the open as if they were decentralized, but they're controlled by the foundation. They're centralized to start. And we're not pretending they're not, right? But we're doing this because that's how we learn. That's how we can learn to make these structures actually operate in a decentralized way. And then over time, we decentralize them bit by bit in a public, you know, open discussion with the community. It's because we have two contradictory things that we have to do. Like we have billions of dollars in TVL. We can't play with that. We have to make sure that that's secure. So we need both a minimal, secure, and stable governance system to minimize risk, but we also need to do something that hasn't been done before. We need to make it effective, too. We have to be radical, innovative, and experimental in order to invent this future. So in order to do that, we've created what we call version control governance. It's like a two-track system of governance. We've got the core system, which is the secure layer. It's handling just the minimal stuff that's needed to make sure the protocol is working. And that stays, you know, if that needs to be more centralized, okay, it's as decentralized as it can be. And then we have the vision track. And the vision track is where we're experimental. And we're creating the systems that will be able to merge back in over time into core once they've proven themselves to be effective. So let me tell you about what we're making. So it's I can gov is what we're calling it. It's this is going to be a very brief overview. We haven't launched this stuff yet. We will soon. So if there's a lot of questions, some of this might not make so much sense. I'm going to do the best I can. We'll be publishing a lot more of this over time. So in designing iGov, we started kind of at the beginning. What do organizations need to do? And there's kind of three things. There's decisions, there's decision makers and then there's decision making and that's how organizations both centralized and decentralized function decisions are the same stuff that we've always had what should we do who's in charge how much does it cost it's variations of this so we don't need to worry too much about that we're not fundamentally changing what a decision is but decision making decision makers there's a lot of room for change decision Decision-making has done a lot of development over the past five years on-chain voting, off-chain voting, multi-sigs, rough consensus, all the different things that we use to do decentralized governance continue to be developed, continue to need more advancement as well. Decision-makers need a bit more work. So decision-makers are things like unique human beings, which supposedly can make good decisions in democracies. We also have tokens, which supposedly can make good decisions in DAOs, or delegates, where you take 100% of your voting power and you delegate it to another human to make decisions on 100% of the things in a DAO, regardless of what they're good at or not. These are not such great decision makers, in my view, and so we're trying to improve this. The first step is we're not doing token voting. Token voting itself, I mean, this is a bit of a nuanced one because we are doing token voting, but we're not doing normal token voting. Token voting in its normal form, you know, is what I said. You have a governance token, and whoever owns this token now can say things about any matter. They're a security expert, or they're a capital allocation expert, but this isn't true. And one of the myths, I think, that we need to break and douse, I think there's this idea that's kind of beautiful that we're just going to be able to put together a big group of strangers and the collective intelligence of that group is just going to solve our problems. We're just going to give our responsibility to this group and they're just going to make things work. And that's a myth. That's not true. Decision making, business, operations, organizations, these are things that require responsibility, accountability, relationships over time. You can't just give this to an anonymous group of people. Now, anonymous groups of people can make certain classes of decisions quite well, but they can't do these in a vacuum. You know, Vitalik's written about this convex, concave decision making. And it's true that you want to estimate an average of certain types of decisions that a large group might do better than a small group. But again, these decisions don't happen in vacuums. So what happens is if you give this power of an organization to just the wisdom of the crowd, you might get decisions that work in a small box but they don't work in reality, like giving hundreds of millions of dollars for grants when you don't have the ability to really oversee it. And this is not just one group. Many groups make decisions like this. But if you're a small group of people with relationships and accountability and things at stake, you probably won't make those decisions. Another thing about token voting is that, you know, going back, tokens, using a crypto-economic token to, you know, provably make a decision about something is a great system. That's great. The problem is who are the deciders that are using that? What is the structure around it? Often there's this idea about governance fatigue, like this is the problem. Governance fatigue, if you think governance fatigue is the problem, you're seeing the thing completely wrong. It's not, that means you're giving people the wrong jobs to do. What you need to do is we need to give people the right jobs to do and then and they won't be fatigued. So in Eigengov, the starting premise, we're not sacrificing on decision-making quality. All decisions are made by small groups of high-context, high-trust domain experts. That's the foundation. That's where we start. Why? Because we do have a superintelligence on this planet, and it's not an LLM, and it's unsure if that will even get there. The greatest superintelligence that we intelligence on this planet and it's not an LLM and it's unsure if that will even get there. The greatest super intelligence that we have on the planet is a group of seven people that trust each other and have worked together for a long time or fewer. That is the smartest thing that we know of and we've known this for a while. But a lot of research shows is after about seven, intelligence drops about 10% per person. And once you get up to large group sizes, you get pretty dumb. So we're trying to hit that sweet spot of a small group. And this is, you know, like a family, like a small team. This is what does the best decision-making. So we start there. Why? And then we can talk a lot about why, but if you look at the relationships, so work in life and creative work, it's about relationships. If you have a group, you have two people, one relationship, three people, three relationships, then four, six relationships, 10 relationships, 15. Each relationship needs to be maintained. Each relationship is a vector that can have misunderstanding, conflict, tension, confusion. So as you grow, it becomes unwieldy. But we can manage in small sizes. This is slime mold. It's not a non sequitur. So if we wanted to keep scaling and just think we want a homogenous group of decision makers, the best we can think of is maybe slime mold. So slime mold is all these different cells. They're all kind of the same cell, but there's lots of them. And they make decisions as a group, and they do pretty miraculous things. But, you know, it's kind of limited. What we need is actually something more like a fly brain. Now, this is a heterogeneous group of centralized and decentralized actors woven together in really complicated ways to make complicated decisions. This is what we need for DAOs. And so, I can go starts with this idea of small teams making decisions. And it starts with the idea of councils. And councils, a variety of councils will talk about them, is how all decisions get made. Now, how do the councils get populated? Elections are a great way to put popular people in charge of things, but not a great way to necessarily put the right people in charge of things. We've created a system called endorsements, which is a way to create reputation. And decentralized reputation is a research area that we're super invested in and will be very important in the future. A lot of people are working on. So we'll talk more about endorsements and also decisions. Decisions is how we actually weave all this stuff all together And we're working with incredible partners like Tally and hats and EAS and others to build all this stuff So this by the way is speculative so left terrorists don't yell at me if this isn't what happens We plan to make a variety of councils and And using the incubation process, powers will incubate within foundation and then they will be spawned into councils, groups of powers, and then over time as they mature, spawn into more councils, pending the amount of overhead needed to make all these things work together. But this creates a better distribution of powers more checks and balances more specialization so each council is a group of high trust high context expert domain experts in the field that they're making decisions on each council has a limited scope of power in the constrained delegation model which they can act in and many of these will be borgs just like like what Gabe was talking about previously. Endorsements, how we find people for these councils, it's similar to delegation. This is a sneak peek at the endorsements platform that we're making. But instead of delegation, again, you delegate 100% of your voting power to one person. With endorsements, when you sign up to be a contributor, which is our version of a delegate, you say, what are you good at? So Roger's good at auditing, governance, and leadership. And so when you trust Roger by using your stake diagram and allocating it to Roger to make decisions, it's according to those specific skills that he's now empowered. And this does a number of things in the system. It also increases your voice. So you'll be able to signal on all proposals. We'll talk about this in a second, rather than just eventually filling council seats. So I want to talk about how decisions get made. This is what a lot of DAOs, the model that a lot of DAOs follow. So you have token holders that can either become delegates themselves or they can delegate their token stake to delegates. And then those delegates vote on proposals. And those delegates then elect members to councils who can also occasionally vote or veto on proposals. So we changed this model quite a bit. In our model, token stakers who have something at stake, they're not just holding the tokens to sell them, can be curators or contributors. And I'm going to pause here for a second because this curator one is kind of new. So when you're a curator, you are making endorsements. So perhaps you're a token staker, but you don't know who is the best at OPSEC in the system. So you can just assign your tokens to a curator, and then the curator is the one that's paying attention to all the contributors in the system. And then similar actually to what Denison was talking about previously in the talk, when you want to make money from staking tokens in a governance system, you want to make sure that if the incentives are coming from people taking action in governance, which was our plan as well, then you want to make sure that your endorsements are going to people that are going to be creating value because you'll be incentivized for it in the future. Curators also solve a big problem in DAOs, which is liveness. Most DAOs, there's an airdrop. People come in, they claim their stuff, they delegate to it, they send their tokens to a delegate, and then that never moves. That token power is just not moving. That's not a very good map of the world. For an organism to be intelligent, it needs to create an updated map of its environment, and so liveness is key to that. These curators, people who are curators are going to be incentivized for keeping a high quality map of who is contributing, as well as evaluating those contributors over time, which is outside the scope of this talk for now. So you can assign a curator, or you can endorse a contributor for various skills. Now the contributors that get the highest endorsements with most trust and relevant skills can then be eligible for councils and eventually will automatically fill councils and then councils vote on proposals. But token stakers need to have ultimate authority. So they can veto proposals in many cases that they don't agree with. And in the worst case, they can fork the intersubjective eigen token if the governance gets captured. So and then the last piece here is about expert signaling. So this is how decisions get made. There's a discussion phase, then there's the council voting phase, and then after that there's the veto period. That whole time there's a phase of expert signaling. So contributors that have gained reputation in the system for various skills can weigh in on every proposal. And this is a sense-making advancement to support council decisions. It's non-binding but it's important and the people that are in the community need to be in discussion right so if there's a controversial proposal and the the community can discuss it, experts can signal on it and the council can vote and the council might have some idea if they're gonna get vetoed or not before that stage happens through this right but you want that small group of people to be able to take anti-majoritarian action because they might not know things that the rest don't and they are there for a reason. So there's a balance. And that's most of it. So I just want to talk a little bit about the future. We have a lot of research to do and a lot of work to do to make all this happen, right? Because this stuff hasn't been figured out yet. That's why it's not a DAO. It's not tested. We have to work on it before it's really decentralized. So there's a few areas I really want to focus on. One is we need to create a system of decentralized reputation. And there's a lot of work there. There's a lot of things I want to say about it, but I don't have time, so I'm going to skip it for now. For decentralized reputation to work, we need decentralized identity. And we also need evaluation systems, accountability, incentivization systems for these types of decentralized systems. Because if we don't lot of these things. We also need to do productization. DAOs are a mess. We need to apply product development standards to the way our DAO tooling and systems work, so that all information and processes have UX that works, people can understand and figure out how to use. And we also need to have credible commitments. This, along with decentralized reputation, is what will allow for these things to really function at a high velocity and change this kind of messy, beautiful experimentalization period into really the future of work, where high-velocity, small teams of groups come together in ad hoc ways to create products and incentives and get retroactively funded, build things, deploy them and then break up and go on to other jobs. The nature of the firm is changing dramatically from these large centralized vertically integrated systems to these small groups of autonomous sovereign contributors able to gain reputation, to gain incentive, to make to make use of their gifts in the world because all these problems that we have the Meta Crisis everything is all solvable with all the gifts in all of you and all of us in the world if we can figure out a governance system, a system to support us in offering all of these gifts to the world and in service of solving these challenges and taking our civilization to the next level. So that's everything. I'm Triky Optrix. Thank you. Thank you so much. Thank you so much, Amanda. That was awesome. And people, you're finally using the application to ask the questions. So we have a few questions here already. Do you want me to... I'll use the votes. I'll use the votes to start choosing the questions. So the first question is, the endorsement system is overly similar to expertise endorsements on LinkedIn, which were removed due to their ineffectiveness. How is this different than LinkedIn with tokens? It's a great question, and it's not oddly similar. I mean, we looked at systems like LinkedIn. Without a good system of decentralization, of reputation, without a way to incentivize good endorsements and punish bad endorsements, it's not much any different than LinkedIn. So right now, it's quite similar. In the future, it will be quite different. Awesome. Next question. Consuls with limited scope can have domain experts that are in multiple consuls, leading to a scope creep. Any plans for council service limits or requirements? Yeah, definitely. There'll be term limits, and there'll be eligibility requirements, and there'll be legal contracting in some cases. There'll be KYC in some cases. And I don't know, I think probably people will just be able to be on one council at a time, but there might be some cases where it's appropriate to be on two. We'll figure that out as we go. But being on two could create conflicts of interest that we want to avoid. We'll have to see. Awesome. Tough questions. The current design seems similar to OP's promise of we will decentralize. What accountability will Agen have to actually make progress? We know we don't. We don't have any. I mean, companies can do whatever they want, right? Like, OP doesn't have to decentralize. I think you have to look at what's in our interest. So if EigenLayer doesn't decentralize, I think over time that it causes a lot of problems for us. And so we can say whatever we want, but look and see what we do. Awesome. So how to avoid that delegates just elect councils who will create things good for them, then later they will approve? Yeah. So there's three key things. So I just kept it to decentralized and effective, but actually there's a third one that's really important too, which is alignment. So you want to, it's the principal agent problem, right? How do you know that your investment broker isn't just making trades that stack his bank account or her bank account? This is, I like to turn this around and we actually think of it as the principal agent solution because the alternative is that you are both principal and agent and nobody's got time for that, right? So it's a huge solution to be able to split things up from ownership to control. But how do you keep that alignment? It's super tricky. And most of our research path is designed around solving exactly this question. Decentralized reputation is a key piece of that. So if, which is also outside the scope of this discussion, but let's say that there is, we believe there's ways to incentivize reputation system using things like trust assignments and the endorsements that we're doing, skill assignments, to make it much more aligned than it is today. But just wait. We'll share more on this soon. Good, good. Any way to transit tree-like decision structure to decentralized structure? You're going to transit a tree-like decision structure to a decentralized structure. I mean, I'm a little confused by the question. Somebody want to speak to that? A tree-like structure could be decentralized. Are you saying like a hierarchical structure? We can skip it. Okay. We can go with the last question. And it's the control of token holders is limited, removing value from the token plus accrued value to console positions instead. Abero is significantly less power than the power to do. Why token at all then? Well, the token isn't for governance. The token is for interest-rejected forking. It's not a governance token. But why use the token in governance? Well, because token holders are the owners of the protocol. And if they always have a governance action that they can take, which is to sell their tokens. But before you sell your tokens, why not, you know, you should have voice as well. We believe one of the things I could have mentioned in this talk is that everybody in the ecosystem has value. The token holders, the AVSs, the operators, the LRTs, everyone building on it, all the partners, all have value. And one of the big magic of putting together a governance system is figuring out how to help that value flourish in the right ways. And what's the right job? What's finding the right job for the right group? And token holders have a really important job. They're the ones whose finances are at stake based on the actions of the organization. And so you want to give them a lever. You want to give them a voice. The problem is giving them the voice of making all decisions for a DAO is just not a very good connection of skills and opportunity, right? Or skills and challenge. So what is the appropriate voice for them? And we feel that the appropriate voice, it's two things, right? One is deciding on who makes the decisions, right? Which is similar to a lot of forms of nation-state governance. So they can endorse contributors that then have the power to make decisions. And they're in charge of those endorsements. They're in charge of curating the space. But then they also have this fear response, like in a body, like we're creating a body. There's another thing I could have talked to, there's an executive council that is a kind of authority, the top authoritarian layer, then there's expert councils, most of the councils making these domain specific decisions, then there's the majority layer of token holders and reputation holders that are curating the space, vetoing the space, and at the bottom, there's this self-enforcing layer of token forking. So, yeah, token holders have a really important role, but it's just not the role that we're used to. Okay, thank you so much. And people, please put those hands together for Tricky After Risk.",
"eventId": "devcon-7",
- "slot_start": 1731557580000,
- "slot_end": 1731558000000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/160SSgpDZHkjg4YniAuH3mYD1hx7hZuv_Qp2ip0zoRso"
+ "slot_start": 1731403800000,
+ "slot_end": 1731405600000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/12GuPqjQk66_MOFYNzQAXdDgl9b2uXDcWEc4im_qwX7E",
+ "resources_slides": null,
+ "speakers": [
+ "tracheopteryx"
+ ]
},
"vector": [
- 0,
- 6,
0,
0,
0,
@@ -753207,6 +751612,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -754080,8 +752486,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -754102,7 +752506,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -754511,9 +752914,10 @@
2,
0,
0,
- 2,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -754529,43 +752933,41 @@
},
{
"session": {
- "id": "the-next-700-evm-languages",
- "sourceId": "QE7RWH",
- "title": "The Next 700 EVM Languages",
- "description": "What is the role of programming languages in helping smart contracts become reliable and scalable technology? Are our current languages for the EVM up to the task? Has Ethereum lost the lead in this regard?\r\nThis talk explores these questions and proposes a roadmap for the development of the next generation of smart contract languages for the EVM.",
- "track": "Developer Experience",
- "type": "Talk",
+ "id": "the-next-generation-of-governors-will-be-modular",
+ "sourceId": "DEAUWE",
+ "title": "The next generation of governors will be modular!",
+ "description": "Onchain governance is one of the main non-financial usecases of ethereum. Still, innovation in that space is slow, and deployed solution are still very much tighted to financial assets. In order to move away from that situation, and build more powerfull governance solution, we need to build a more modular and evolutive approach.",
+ "track": "Coordination",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "programming languages",
- "formal verification",
- "smart contracts"
+ "Smart contracts",
+ "modularity"
],
"tags": [
- "Languages",
- "Formal Verification",
- "smart",
- "contracts"
+ "Governance",
+ "Design",
+ "modular",
+ "Design",
+ "Governance"
],
"language": "en",
"speakers": [
- "francisco-giordano"
+ "hadrien-croubois"
],
"eventId": "devcon-7",
- "slot_start": 1731580200000,
- "slot_end": 1731582000000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1xFEtAafqxxm1b1UAUHGb8bnoWg9x6qZQdGRk_3lPM8Y"
+ "slot_start": 1731489600000,
+ "slot_end": 1731490200000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1DnvD2EnuiJkqkdlnAA1h6CZl0zqKU90ShcgX4KV0SrE"
},
"vector": [
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -754574,6 +752976,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -755407,11 +753810,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -755455,6 +753857,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -755510,7 +753913,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -755572,8 +753974,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -755620,6 +754020,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -755896,46 +754297,27 @@
},
{
"session": {
- "id": "the-next-era-sequencing-and-its-real-impact-on-app-users",
- "sourceId": "9M78AK",
- "title": "The Next Era: Sequencing and Its Real Impact on App Users",
- "description": "This talk will discuss app sequencing products which were developed to enhance decentralization and security via distributed transaction ordering with independent sequencing (native Mainnet L2 sequencers i.e. Base, OP) and the impact to end users and applications. It will also discuss the tradeoffs of LVR, shared sequencing, and app-specific sequencing.",
- "track": "Usability",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Product",
+ "id": "the-open-source-orchestra",
+ "sourceId": "9PWLBV",
+ "title": "The Open Source Orchestra",
+ "description": "Member of the Open Source Orchestra",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "Expert",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Layer 2s",
- "User Experience",
- "Transaction fees mechanisms",
- "sequencer",
- "Layer 2s",
- "Transaction fees mechanisms",
- "User Experience"
- ],
- "keywords": [
- "Sequencing"
- ],
- "duration": 975,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "707cb042ec5704ebd467c773dedb087d6fc5a3c474c0c41441a2ed12ac9ec02d",
- "sources_youtubeId": "-S2rlhSUHZY",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731405600000,
- "slot_end": 1731407400000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1l63vZZz_0RN-aU0hwjhmdAat5Fq0OFy7UoMYiS3KJxc",
- "resources_slides": null,
"speakers": [
- "tina-haibodi"
- ]
+ "sophia-spirlock"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731553200000,
+ "slot_end": 1731556800000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1MLErEiLaty6zwbafFEy3AROdYSwqpoEoEBnY5JL_9YY"
},
"vector": [
0,
@@ -755946,6 +754328,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -756587,9 +754970,22 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
- 6,
0,
0,
0,
@@ -756706,7 +755102,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -756730,7 +755125,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -756756,7 +755150,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -756802,17 +755195,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -757252,6 +755634,7 @@
0,
0,
2,
+ 2,
0,
0,
0,
@@ -757259,10 +755642,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -757273,42 +755652,36 @@
},
{
"session": {
- "id": "the-next-generation-of-decentralized-governance",
- "sourceId": "WUSAHA",
- "title": "The Next Generation of Decentralized Governance",
- "description": "In this talk, tracheoptryx will share thoughts on what will define the next phase of decentralized governance and how that has informed the design of EigenGov, EigenLayer’s forthcoming governance system.",
- "track": "Coordination",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "id": "the-political-economy-of-dacc",
+ "sourceId": "AXX3JD",
+ "title": "The political economy of d/acc",
+ "description": "The dynamics behind d/acc are not new. Economic history is full of examples of the private provision of public goods. If we want to reduce AI risks while preserving freedom from centralized control, it's worth thinking carefully about the different ways humans have solved isomorphic problems in the past, and how the same tools could apply today.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "tags": [],
"keywords": [
- "see",
- "doc"
+ "d/acc"
+ ],
+ "tags": [
+ "Public",
+ "good"
],
- "duration": 1629,
"language": "en",
- "sources_swarmHash": "75a12cae9fadbaeaba434231a49a634d15b4251288154859b4667cd19622b603",
- "sources_youtubeId": "VhkP2OIwIFY",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333c273a168eb535f16a85.vtt",
- "transcript_text": " All right, so yeah, I'm really happy to be here. Take a moment to just enjoy that for a second. Hey, everyone. So I'm going to be speaking about decentralized governance today. I'm Trey Kioptririx. I'm a dinosaur. I am the chief governance officer at EigenLayer, or at the Eigen Foundation. That's where I'm working. Previously, I worked at, I was a contributor to Yearn Finance, where the gentleman who's leaving right now spoke before Gabe Shapiro and I both designed a governance system called Constrained Delegation, which informs a lot of the work that you just saw in Borgs and also what we're building at Eigenlayer. I also was a co-founder of Coordinate, which is a system for decentralized compensation. So I want to start, why does it even matter? Why do we need decentralized governance? Why is it important? I think we talk a lot about governance minimization, which is really important. If you can minimize it, do. But there's no way to minimize things at the frontier. You can't reduce the most new, confusing, misunderstood things into immutable code. There are periods where human beings have to come together in subjective reality and reason things out and make decisions together. We need some form of collective decision making, and we always will. And the forms that we have now and have for centuries aren't so great. They lead to wars and various other things. So beyond just the ability to launch a token and not get sued, decentralized governance has the potential to do much, much more. It has the potential to give us ways to not stop killing each other, for instance, which we haven't figured out as a species. It's a tall order, and there's a lot to do to get there, obviously. But, you know, here we have three predators that are already doing it. So we're going to take our cues from them. I want to talk a little bit about what DAOs are doing now before we talk about the future of decentralized governance. So today, DAOs are really good things, like increased transparency in organizations. Beautiful. More permissionless access to information and control. Capture resistance. more permissionless access to information and control capture resistance all these on-chain technologies allow for much greater security and to reduce capture by small groups give more access to people and they allow for decentralized decision-making which has been an incredible advance over the past you years, eight years. But it's not all happy stories, right? There's a sad dog as well. For instance, DAOs are pretty bad at power concentration. If you look at a lot of what seem like decentralized DAOs, you find that under the hood, they're maybe not so decentralized. They're also bad at skill-task matching, which is something we'll talk about a little bit more. There's tons of principal agent problems all throughout DAOs and low accountability. And while they're doing decentralized decision making, I'd argue that it's pretty ineffective low quality decision making in most cases. So what's the next generation? So far we've done well at decentralizing. But what's next? And it's pretty simple. It's making them decentralized and effective, which we don't really have any examples of today. But we're getting there. And so that's what we're working on at EigenLayer. So EigenLayer, we're doing Ethereum restaking, helping create a new ecosystem of AVSs and taking things off-chain, putting them on-chain on Ethereum to expand what's possible. This is a big, ambitious vision. It's a big, open ecosystem that we're building, and we need effective and decentralized governance. We need the people building on EigenLayer to have control and ownership over what happens on the commons that we're creating together. And it has to be, you know, for now, it's a tricky question. Decentralized or effective, right? You can kind of choose one. We don't have the technologies to do both yet. So in the beginning, it's kind of okay to be a little bit more centralized. And if Lefteris is out there, we're not a DAO yet, right? We're trying, but we're not yet. We're starting more centralized, and we're going to decentralize over time. And that's because we're focusing on quality decision-making. We're not going to give that up, and we believe that we can do both. But later, over time, it really does have to be centralized because you can only trust, you know, in the beginning the participants in the ecosystem need to know that Eigen layer is making good decisions, right? But over time after the, you know, honeymoon period is worn off, you need to trust that they're not going to screw you. And that needs to be decentralized. So we have this process we call incubation, which is our version of progressive decentralization. And in progressive decentralization usually, you know, you have a foundation which has the power, and it controls everything, and then it gives a chunk of power to a DAO, and then another chunk of power to the DAO. It's good. We're adding more gradation to this. So our version of this incubation, we take decentralized structures, and we operate them in the open as if they were decentralized, but they're controlled by the foundation. They're centralized to start. And we're not pretending they're not, right? But we're doing this because that's how we learn. That's how we can learn to make these structures actually operate in a decentralized way. And then over time, we decentralize them bit by bit in a public, you know, open discussion with the community. It's because we have two contradictory things that we have to do. Like we have billions of dollars in TVL. We can't play with that. We have to make sure that that's secure. So we need both a minimal, secure, and stable governance system to minimize risk, but we also need to do something that hasn't been done before. We need to make it effective, too. We have to be radical, innovative, and experimental in order to invent this future. So in order to do that, we've created what we call version control governance. It's like a two-track system of governance. We've got the core system, which is the secure layer. It's handling just the minimal stuff that's needed to make sure the protocol is working. And that stays, you know, if that needs to be more centralized, okay, it's as decentralized as it can be. And then we have the vision track. And the vision track is where we're experimental. And we're creating the systems that will be able to merge back in over time into core once they've proven themselves to be effective. So let me tell you about what we're making. So it's I can gov is what we're calling it. It's this is going to be a very brief overview. We haven't launched this stuff yet. We will soon. So if there's a lot of questions, some of this might not make so much sense. I'm going to do the best I can. We'll be publishing a lot more of this over time. So in designing iGov, we started kind of at the beginning. What do organizations need to do? And there's kind of three things. There's decisions, there's decision makers and then there's decision making and that's how organizations both centralized and decentralized function decisions are the same stuff that we've always had what should we do who's in charge how much does it cost it's variations of this so we don't need to worry too much about that we're not fundamentally changing what a decision is but decision making decision makers there's a lot of room for change decision Decision-making has done a lot of development over the past five years on-chain voting, off-chain voting, multi-sigs, rough consensus, all the different things that we use to do decentralized governance continue to be developed, continue to need more advancement as well. Decision-makers need a bit more work. So decision-makers are things like unique human beings, which supposedly can make good decisions in democracies. We also have tokens, which supposedly can make good decisions in DAOs, or delegates, where you take 100% of your voting power and you delegate it to another human to make decisions on 100% of the things in a DAO, regardless of what they're good at or not. These are not such great decision makers, in my view, and so we're trying to improve this. The first step is we're not doing token voting. Token voting itself, I mean, this is a bit of a nuanced one because we are doing token voting, but we're not doing normal token voting. Token voting in its normal form, you know, is what I said. You have a governance token, and whoever owns this token now can say things about any matter. They're a security expert, or they're a capital allocation expert, but this isn't true. And one of the myths, I think, that we need to break and douse, I think there's this idea that's kind of beautiful that we're just going to be able to put together a big group of strangers and the collective intelligence of that group is just going to solve our problems. We're just going to give our responsibility to this group and they're just going to make things work. And that's a myth. That's not true. Decision making, business, operations, organizations, these are things that require responsibility, accountability, relationships over time. You can't just give this to an anonymous group of people. Now, anonymous groups of people can make certain classes of decisions quite well, but they can't do these in a vacuum. You know, Vitalik's written about this convex, concave decision making. And it's true that you want to estimate an average of certain types of decisions that a large group might do better than a small group. But again, these decisions don't happen in vacuums. So what happens is if you give this power of an organization to just the wisdom of the crowd, you might get decisions that work in a small box but they don't work in reality, like giving hundreds of millions of dollars for grants when you don't have the ability to really oversee it. And this is not just one group. Many groups make decisions like this. But if you're a small group of people with relationships and accountability and things at stake, you probably won't make those decisions. Another thing about token voting is that, you know, going back, tokens, using a crypto-economic token to, you know, provably make a decision about something is a great system. That's great. The problem is who are the deciders that are using that? What is the structure around it? Often there's this idea about governance fatigue, like this is the problem. Governance fatigue, if you think governance fatigue is the problem, you're seeing the thing completely wrong. It's not, that means you're giving people the wrong jobs to do. What you need to do is we need to give people the right jobs to do and then and they won't be fatigued. So in Eigengov, the starting premise, we're not sacrificing on decision-making quality. All decisions are made by small groups of high-context, high-trust domain experts. That's the foundation. That's where we start. Why? Because we do have a superintelligence on this planet, and it's not an LLM, and it's unsure if that will even get there. The greatest superintelligence that we intelligence on this planet and it's not an LLM and it's unsure if that will even get there. The greatest super intelligence that we have on the planet is a group of seven people that trust each other and have worked together for a long time or fewer. That is the smartest thing that we know of and we've known this for a while. But a lot of research shows is after about seven, intelligence drops about 10% per person. And once you get up to large group sizes, you get pretty dumb. So we're trying to hit that sweet spot of a small group. And this is, you know, like a family, like a small team. This is what does the best decision-making. So we start there. Why? And then we can talk a lot about why, but if you look at the relationships, so work in life and creative work, it's about relationships. If you have a group, you have two people, one relationship, three people, three relationships, then four, six relationships, 10 relationships, 15. Each relationship needs to be maintained. Each relationship is a vector that can have misunderstanding, conflict, tension, confusion. So as you grow, it becomes unwieldy. But we can manage in small sizes. This is slime mold. It's not a non sequitur. So if we wanted to keep scaling and just think we want a homogenous group of decision makers, the best we can think of is maybe slime mold. So slime mold is all these different cells. They're all kind of the same cell, but there's lots of them. And they make decisions as a group, and they do pretty miraculous things. But, you know, it's kind of limited. What we need is actually something more like a fly brain. Now, this is a heterogeneous group of centralized and decentralized actors woven together in really complicated ways to make complicated decisions. This is what we need for DAOs. And so, I can go starts with this idea of small teams making decisions. And it starts with the idea of councils. And councils, a variety of councils will talk about them, is how all decisions get made. Now, how do the councils get populated? Elections are a great way to put popular people in charge of things, but not a great way to necessarily put the right people in charge of things. We've created a system called endorsements, which is a way to create reputation. And decentralized reputation is a research area that we're super invested in and will be very important in the future. A lot of people are working on. So we'll talk more about endorsements and also decisions. Decisions is how we actually weave all this stuff all together And we're working with incredible partners like Tally and hats and EAS and others to build all this stuff So this by the way is speculative so left terrorists don't yell at me if this isn't what happens We plan to make a variety of councils and And using the incubation process, powers will incubate within foundation and then they will be spawned into councils, groups of powers, and then over time as they mature, spawn into more councils, pending the amount of overhead needed to make all these things work together. But this creates a better distribution of powers more checks and balances more specialization so each council is a group of high trust high context expert domain experts in the field that they're making decisions on each council has a limited scope of power in the constrained delegation model which they can act in and many of these will be borgs just like like what Gabe was talking about previously. Endorsements, how we find people for these councils, it's similar to delegation. This is a sneak peek at the endorsements platform that we're making. But instead of delegation, again, you delegate 100% of your voting power to one person. With endorsements, when you sign up to be a contributor, which is our version of a delegate, you say, what are you good at? So Roger's good at auditing, governance, and leadership. And so when you trust Roger by using your stake diagram and allocating it to Roger to make decisions, it's according to those specific skills that he's now empowered. And this does a number of things in the system. It also increases your voice. So you'll be able to signal on all proposals. We'll talk about this in a second, rather than just eventually filling council seats. So I want to talk about how decisions get made. This is what a lot of DAOs, the model that a lot of DAOs follow. So you have token holders that can either become delegates themselves or they can delegate their token stake to delegates. And then those delegates vote on proposals. And those delegates then elect members to councils who can also occasionally vote or veto on proposals. So we changed this model quite a bit. In our model, token stakers who have something at stake, they're not just holding the tokens to sell them, can be curators or contributors. And I'm going to pause here for a second because this curator one is kind of new. So when you're a curator, you are making endorsements. So perhaps you're a token staker, but you don't know who is the best at OPSEC in the system. So you can just assign your tokens to a curator, and then the curator is the one that's paying attention to all the contributors in the system. And then similar actually to what Denison was talking about previously in the talk, when you want to make money from staking tokens in a governance system, you want to make sure that if the incentives are coming from people taking action in governance, which was our plan as well, then you want to make sure that your endorsements are going to people that are going to be creating value because you'll be incentivized for it in the future. Curators also solve a big problem in DAOs, which is liveness. Most DAOs, there's an airdrop. People come in, they claim their stuff, they delegate to it, they send their tokens to a delegate, and then that never moves. That token power is just not moving. That's not a very good map of the world. For an organism to be intelligent, it needs to create an updated map of its environment, and so liveness is key to that. These curators, people who are curators are going to be incentivized for keeping a high quality map of who is contributing, as well as evaluating those contributors over time, which is outside the scope of this talk for now. So you can assign a curator, or you can endorse a contributor for various skills. Now the contributors that get the highest endorsements with most trust and relevant skills can then be eligible for councils and eventually will automatically fill councils and then councils vote on proposals. But token stakers need to have ultimate authority. So they can veto proposals in many cases that they don't agree with. And in the worst case, they can fork the intersubjective eigen token if the governance gets captured. So and then the last piece here is about expert signaling. So this is how decisions get made. There's a discussion phase, then there's the council voting phase, and then after that there's the veto period. That whole time there's a phase of expert signaling. So contributors that have gained reputation in the system for various skills can weigh in on every proposal. And this is a sense-making advancement to support council decisions. It's non-binding but it's important and the people that are in the community need to be in discussion right so if there's a controversial proposal and the the community can discuss it, experts can signal on it and the council can vote and the council might have some idea if they're gonna get vetoed or not before that stage happens through this right but you want that small group of people to be able to take anti-majoritarian action because they might not know things that the rest don't and they are there for a reason. So there's a balance. And that's most of it. So I just want to talk a little bit about the future. We have a lot of research to do and a lot of work to do to make all this happen, right? Because this stuff hasn't been figured out yet. That's why it's not a DAO. It's not tested. We have to work on it before it's really decentralized. So there's a few areas I really want to focus on. One is we need to create a system of decentralized reputation. And there's a lot of work there. There's a lot of things I want to say about it, but I don't have time, so I'm going to skip it for now. For decentralized reputation to work, we need decentralized identity. And we also need evaluation systems, accountability, incentivization systems for these types of decentralized systems. Because if we don't lot of these things. We also need to do productization. DAOs are a mess. We need to apply product development standards to the way our DAO tooling and systems work, so that all information and processes have UX that works, people can understand and figure out how to use. And we also need to have credible commitments. This, along with decentralized reputation, is what will allow for these things to really function at a high velocity and change this kind of messy, beautiful experimentalization period into really the future of work, where high-velocity, small teams of groups come together in ad hoc ways to create products and incentives and get retroactively funded, build things, deploy them and then break up and go on to other jobs. The nature of the firm is changing dramatically from these large centralized vertically integrated systems to these small groups of autonomous sovereign contributors able to gain reputation, to gain incentive, to make to make use of their gifts in the world because all these problems that we have the Meta Crisis everything is all solvable with all the gifts in all of you and all of us in the world if we can figure out a governance system, a system to support us in offering all of these gifts to the world and in service of solving these challenges and taking our civilization to the next level. So that's everything. I'm Triky Optrix. Thank you. Thank you so much. Thank you so much, Amanda. That was awesome. And people, you're finally using the application to ask the questions. So we have a few questions here already. Do you want me to... I'll use the votes. I'll use the votes to start choosing the questions. So the first question is, the endorsement system is overly similar to expertise endorsements on LinkedIn, which were removed due to their ineffectiveness. How is this different than LinkedIn with tokens? It's a great question, and it's not oddly similar. I mean, we looked at systems like LinkedIn. Without a good system of decentralization, of reputation, without a way to incentivize good endorsements and punish bad endorsements, it's not much any different than LinkedIn. So right now, it's quite similar. In the future, it will be quite different. Awesome. Next question. Consuls with limited scope can have domain experts that are in multiple consuls, leading to a scope creep. Any plans for council service limits or requirements? Yeah, definitely. There'll be term limits, and there'll be eligibility requirements, and there'll be legal contracting in some cases. There'll be KYC in some cases. And I don't know, I think probably people will just be able to be on one council at a time, but there might be some cases where it's appropriate to be on two. We'll figure that out as we go. But being on two could create conflicts of interest that we want to avoid. We'll have to see. Awesome. Tough questions. The current design seems similar to OP's promise of we will decentralize. What accountability will Agen have to actually make progress? We know we don't. We don't have any. I mean, companies can do whatever they want, right? Like, OP doesn't have to decentralize. I think you have to look at what's in our interest. So if EigenLayer doesn't decentralize, I think over time that it causes a lot of problems for us. And so we can say whatever we want, but look and see what we do. Awesome. So how to avoid that delegates just elect councils who will create things good for them, then later they will approve? Yeah. So there's three key things. So I just kept it to decentralized and effective, but actually there's a third one that's really important too, which is alignment. So you want to, it's the principal agent problem, right? How do you know that your investment broker isn't just making trades that stack his bank account or her bank account? This is, I like to turn this around and we actually think of it as the principal agent solution because the alternative is that you are both principal and agent and nobody's got time for that, right? So it's a huge solution to be able to split things up from ownership to control. But how do you keep that alignment? It's super tricky. And most of our research path is designed around solving exactly this question. Decentralized reputation is a key piece of that. So if, which is also outside the scope of this discussion, but let's say that there is, we believe there's ways to incentivize reputation system using things like trust assignments and the endorsements that we're doing, skill assignments, to make it much more aligned than it is today. But just wait. We'll share more on this soon. Good, good. Any way to transit tree-like decision structure to decentralized structure? You're going to transit a tree-like decision structure to a decentralized structure. I mean, I'm a little confused by the question. Somebody want to speak to that? A tree-like structure could be decentralized. Are you saying like a hierarchical structure? We can skip it. Okay. We can go with the last question. And it's the control of token holders is limited, removing value from the token plus accrued value to console positions instead. Abero is significantly less power than the power to do. Why token at all then? Well, the token isn't for governance. The token is for interest-rejected forking. It's not a governance token. But why use the token in governance? Well, because token holders are the owners of the protocol. And if they always have a governance action that they can take, which is to sell their tokens. But before you sell your tokens, why not, you know, you should have voice as well. We believe one of the things I could have mentioned in this talk is that everybody in the ecosystem has value. The token holders, the AVSs, the operators, the LRTs, everyone building on it, all the partners, all have value. And one of the big magic of putting together a governance system is figuring out how to help that value flourish in the right ways. And what's the right job? What's finding the right job for the right group? And token holders have a really important job. They're the ones whose finances are at stake based on the actions of the organization. And so you want to give them a lever. You want to give them a voice. The problem is giving them the voice of making all decisions for a DAO is just not a very good connection of skills and opportunity, right? Or skills and challenge. So what is the appropriate voice for them? And we feel that the appropriate voice, it's two things, right? One is deciding on who makes the decisions, right? Which is similar to a lot of forms of nation-state governance. So they can endorse contributors that then have the power to make decisions. And they're in charge of those endorsements. They're in charge of curating the space. But then they also have this fear response, like in a body, like we're creating a body. There's another thing I could have talked to, there's an executive council that is a kind of authority, the top authoritarian layer, then there's expert councils, most of the councils making these domain specific decisions, then there's the majority layer of token holders and reputation holders that are curating the space, vetoing the space, and at the bottom, there's this self-enforcing layer of token forking. So, yeah, token holders have a really important role, but it's just not the role that we're used to. Okay, thank you so much. And people, please put those hands together for Tricky After Risk.",
- "eventId": "devcon-7",
- "slot_start": 1731403800000,
- "slot_end": 1731405600000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/12GuPqjQk66_MOFYNzQAXdDgl9b2uXDcWEc4im_qwX7E",
- "resources_slides": null,
"speakers": [
- "tracheopteryx"
- ]
+ "eli-dourado"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731553800000,
+ "slot_end": 1731555000000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Ark5gHHkzTiHgbw7rdgfM5t6pIra-jjXvX-Qq1FPlRk"
},
"vector": [
0,
+ 6,
0,
0,
0,
@@ -757319,9 +755692,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -757518,6 +755888,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -757960,7 +756331,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -758567,6 +756937,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -758626,11 +756997,9 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
+ 2,
0,
0,
0,
@@ -758643,36 +757012,40 @@
},
{
"session": {
- "id": "the-next-generation-of-governors-will-be-modular",
- "sourceId": "DEAUWE",
- "title": "The next generation of governors will be modular!",
- "description": "Onchain governance is one of the main non-financial usecases of ethereum. Still, innovation in that space is slow, and deployed solution are still very much tighted to financial assets. In order to move away from that situation, and build more powerfull governance solution, we need to build a more modular and evolutive approach.",
- "track": "Coordination",
+ "id": "the-rated-list",
+ "sourceId": "QNYDCR",
+ "title": "The Rated List",
+ "description": "The Rated List construction aims to minimise the number of requests required to complete sampling in Data Availability Sampling (DAS) for Ethereum. This optimisation becomes especially critical in the context of Full DAS, as data production per slot is anticipated to far exceed the current Deneb-Cancun (Dencun) specifications. The Rated List attempts to improve rate of successful sampling against unfavourable network conditions there by reducing the bandwidth consumption of the overall network.",
+ "track": "[CLS] EPF Day",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Smart contracts",
- "modularity"
- ],
"tags": [
- "Governance",
- "Design",
- "modular",
- "Design",
- "Governance"
+ "DAS",
+ "Data Availability"
],
+ "keywords": [],
+ "duration": 1052,
"language": "en",
- "speakers": [
- "hadrien-croubois"
- ],
+ "sources_swarmHash": "",
+ "sources_youtubeId": "JcP2aVy1Cjc",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": "6734828d9dbb7a90e1dd808a",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734828d9dbb7a90e1dd808a.vtt",
+ "transcript_text": " . Hello, guys. Thank you for coming for the presentation. Okay. I think I . So we are presenting the Rated List. We were mentored by Dankrad on this project. It was his idea originally. What we did was to formally specify the rated list, take it out from a blog, and have a proper set of Pythonic specs for the rated list, build a simulator against which we can test the rated list, write some unit tests so that we have some basic sanity checks test the rated list, write some unit tests so that we have some basic sanity checks of the rated list so that it does not perform worse than just randomly pure sampling, and collect some metrics against known attacks on existing DHTs. So just to give you a quick intro to rated list. Sorry. So, this was the idea proposed by Dankrad, which is instead of having a DST, you form a tree of all the nodes that you know. You ask for, in kind of a peer exchange manner, you ask for nodes of the nodes, and you build out a tree, and you start your peer sampling. based on the peer sampling if a node replies or does not reply you propagate those scores back to all the ancestors right so as you can see the red node is malicious node or a node that does not respond and because of that the scores of its direct parent and its Great-grandparents are affected So this is the basic idea of the rated list This was what was defined in the blog. We went on to further define how you would use filtering over it which is Sorry scoring. Yeah, so once you have every node's descendant score, so if a set of nodes are serving a sample, their descendant scores are not the actual scores that we use for filtering. What we do is we trickle, not trickle basically, but we kind of follow the paths of that node existence in all the subtrees because a node has many peers and it would exist in different subtrees. We take the level one peers scores, which are the best for that node's path, right? So it's the best path score of that node. We use that score, we filter out using a threshold. If the threshold does not work, like if it does not filter out any nodes, we switch to an average score for the same. And basically because we want to complete sampling even though we cannot filter out using the rated list. So that's average filtering. And after filtering, we can apply different querying strategies, which is we can use random querying strategy, we can use the highest score first, we can use the lowest score first, and we can use the average score first. Average score first and lowest score first does not make a lot of sense in the start, but if you think about it, parent node can have a perfect score because none of its children are contacted yet, right? A parent node can have a perfect score because none of its children are contacted yet. So a higher score first wouldn't be the most successful strategy in some cases. You would want to go for the average score because you know that there are some honest nodes balancing out the malicious nodes in that subtree. So there are different squaring strategies that you can apply. And for the rated list, we have defined a default score of 1.0, which is the perfect score. Which is slightly optimistic, but it's fine. Because we do scoring on a per-slot basis. So for every slot, we get all the peers, off-peers, and build a tree, and we start scoring. And we delete the scores for the next slot. We start again, right? Ideally, what we could do is we could propagate these scores into the Gossip Score V1.2 to persist over slots. So we could have that kind of a scoring mechanism as well. Why do we use the rated list, right? The main attack that we are going towards is to defend against a local key space flooding attack through Sybil nodes. We also want to reduce the amount of requests that we sent out for actually completing peer sampling which can be avoided if we can defunct an entire subtree of malicious nodes. I would say that the per-slot tempo matches very nicely with the pure sampling requirements because you can have honest acting malicious nodes, which is default on one particular block. So the entire objective is to complete sampling for that particular slot. honest acting malicious nodes, which is default on one particular block, right? So the entire objective is to complete sampling for that particular slot. So a per-slot sampling sets the tempo right. And lastly, it removes dead subtrees. So if there are any inactive nodes, they would already be removed. And you could assume that we reach a global stability point, like where everyone removes their defunct subtrees. So then coming to the simulator and the simulator's design, we had to play around a lot because for graphs, there are libraries out there, but the ones that are usually used are not that optimized. So we started with the NetworkX library, but it was really slow at generating a random graph with a high degree at number of nodes at 10,000. Right now for all our simulations, we use the degree at 50 and the number of nodes at 10,000, which is like a good assumption for a peer-to-peer sampling network, right? And we use RushWorkX because, as you can see, the benchmarks for graph generation is just the best for all the libraries that are there out there right now. And for querying strategy, we used all four querying strategies, highest, average, lowest, and actually random as well. But we also refilter nodes with a different threshold if we cannot complete sampling, because our objective is to complete sampling at the end of the day. So coming into the architecture of the simulator a little bit, we wanted to modularize everything so that this simulator can practically be used for other kinds of implementations like the rated list in the future. So having it modularized gives you an attack framework because we have written a lot of attacks right now. So you could test against these in the future. So yeah, everything's modularized. We spec convert the rated list spec into a Notepad implementation for all the simulations. I'll give it to Openana. So yeah, that's the simulator. Let me just quickly, I said it's not working. I think it's working. Okay. I mean, just since the slides are off, let's turn the attacks on, I guess. So yeah, I'll quickly brief you guys about the sort of attacks we try to use against our construction. Okay. Yeah. So basically what we try to do is poison the entire network with a lot of randomly picked nodes and mark them as malicious. The only problem with that is that the conditional probability of finding the parent being malicious with the children is almost same as just randomly picking any malicious node from the network. So just randomly marking any node doesn't make sense, and there's not a lot of difference because of the rated list. Although the only attack vector that might cause an issue would be basically trying to attack on one local key space, and that's what we tried to simulate. So yeah, basically trying to mark and enter a subtree to a malicious node, which then gave us the results where we were getting far more better results in terms of rated lists as compared to just randomly. Yeah. There you go. Okay. So yeah, there's a graph plot where we get to see where the rated list performs much better than just randomly picking out nodes and trying to sample. It's in terms of the number of requests that go out. Like for 90 percent of, 70 percent of civil nodes gives us almost double number of requests when doing a random sampling. But in case of a greater list, it's like the lower number. So is it? Okay. Okay. Got it. Okay. Yeah. So there are graphs showing those results and that there's some future work that needs to be done. We are currently researching on this new topic of trying to score the pens in a probabilistic way. Right now, it's just averaging out. So we are trying to take the probabilities of each and every children nodes and then finding the score for the parent based on those scoring for the children. So yeah, that's the scoring mechanism we are trying to work on. And I mean, oh yeah, awesome. So yeah, this is what I was talking about, where we were just randomly poisoning the nodes in the network. You don't really see a massive difference between rated list on and off. So as you can see, there's not a lot of difference, but there's a small difference. But still, this is where we shine, is the rated list performs much better than just randomly sampling from the network in case of 90 percent poisoning. So this is where there was a entire subtree marked as malicious. I think I have a small, yeah. So those are the sort of future work we are trying to do is that, since our implementation is still in like super native like primitive stage right now, so we would like to implement a better simulator. Yeah, I think this probably sums up. Yeah. Yeah. So can you go back to the graph? So just want to point out that all these graphs were done over like 100 runs at different thresholds. Sorry. So all these metrics were plotted over 100 runs with different thresholds and different strategies straight out. And for the rated list, we picked the best score among all different strategies. So best score first, average score first, and everything. Where the rated list off is just plain old naive, randomly sampling from the network. Probably just for visualization, this is the graph that the big blue ball is basically a network, but then it's all pulled out and those are the malicious nodes here. So yeah,, guys. Any questions for these two on the rated list project? Just trying to understand the Sybil graph that you had. You injected lots of Sybil nodes into the tree. And how do you determine which ones were Sybil and which ones weren't? Or have I misunderstood? Are you asking about the implementation detail? No, kind of in general. So a Sybil node would basically not reply for any peer sampling requests coming to it. We can definitely test for more cases where the attacks are more nuanced, as in the adversary can be adaptive, where the Sibyl node only responds to a certain number of nodes but not other nodes. If you want to actually eclipse a particular node, you would flood its local space and not just reply to that particular node, but reply to every other node. So you were detecting the Sybil, you didn't just assume that they were Sybil, right? You didn't just say these ones are malicious, you actually based on their responses, you determined that they were Sybil attacks. Yes. The parent-child relationship that you showed in the graph, how do you come up with the peer parent-child relationship? Is it like if this peer told you about the other peer, then it's child? Yes. So it's much more of a local view rather than a global view, where it's basically just like peer exchange where we just ask for peers from particular node. So first I ask from the nodes that I'm connected to for their peers, and then I make a list of those peers and ask for peers from them as well. I can cap this. Basically, in the rated list, we have it capped at 100 max children per node. So any node could randomly send for every slot, randomly or maybe probabilistically send a certain set of 100 nodes to us. Is this a candidate for replacing CAD-based discovery? It wouldn't replace CAD-based discovery per se. So rated list assumes that you already have a libP2P network. And for discovery, it's not really... You would need bootstrap nodes to actually form this thing, so it becomes a little more complicated over there. But what we are definitely planning on is, like if you think about it, per slot scores, they make sense if you assume that malicious nodes are honest acting until that slot, but then you can also have malicious nodes that start acting honest after that slot, and a per slot score wouldn't really help at that point. But the good thing is the version 1.2 Gossip scoring provides these application scores that you can inject into them, and they are persisted with DK parameters and everything. So we plan on just injecting the rated list score into the Gossip v1.2 scoring. All right, thank you. Let's give it up for these guys one more time.",
"eventId": "devcon-7",
- "slot_start": 1731489600000,
- "slot_end": 1731490200000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1DnvD2EnuiJkqkdlnAA1h6CZl0zqKU90ShcgX4KV0SrE"
+ "slot_start": 1731486600000,
+ "slot_end": 1731487500000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1tvKSVVMilC4YJnTAe-LSaWUsQBBm9OaP3zYQYmWuVJ4",
+ "resources_slides": null,
+ "speakers": [
+ "hopinheimer",
+ "chirag-mahaveer-parmar"
+ ]
},
"vector": [
0,
@@ -758686,13 +757059,11 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -759329,6 +757700,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -759492,6 +757864,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -759523,7 +757896,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -759570,7 +757942,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -759734,8 +758105,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -759782,6 +758151,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -759992,8 +758362,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -760010,27 +758380,37 @@
},
{
"session": {
- "id": "the-open-source-orchestra",
- "sourceId": "9PWLBV",
- "title": "The Open Source Orchestra",
- "description": "Member of the Open Source Orchestra",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "Expert",
- "audience": "Engineering",
+ "id": "the-ripple-effect-of-devcon-vi",
+ "sourceId": "E3U3XU",
+ "title": "The Ripple Effect of Devcon VI",
+ "description": "Devcon VI in Bogotá accelerated community growth across the region. Local communities emerged in several cities in Colombia and Latin America. The gathering provided leaders with a new perspective on enhancing collective creation for social impact and blockchain adoption. At ETH Bogotá, we used this spark to transition from hosting general events to creating an educational system for developers and builders, aiming to push the adoption of blockchain and Ethereum in a new way.",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Education"
+ ],
+ "tags": [
+ "Vision",
+ "Ethereum for Good",
+ "Local Impact",
+ "education",
+ "Ethereum for Good",
+ "Local Impact",
+ "Vision"
+ ],
"language": "en",
"speakers": [
- "sophia-spirlock"
+ "julio-cesar-arango"
],
"eventId": "devcon-7",
- "slot_start": 1731553200000,
- "slot_end": 1731556800000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1MLErEiLaty6zwbafFEy3AROdYSwqpoEoEBnY5JL_9YY"
+ "slot_start": 1731559800000,
+ "slot_end": 1731560400000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1vrrnCLaeOKKIwa7Mc_RpUOzo-jB1B7QzDNcIzCEOrak"
},
"vector": [
0,
@@ -760039,11 +758419,10 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -760874,6 +759253,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -760908,6 +759288,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -761014,6 +759395,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -761022,6 +759404,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -761342,14 +759725,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 0,
- 2,
2,
0,
0,
@@ -761358,44 +759740,54 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "the-political-economy-of-dacc",
- "sourceId": "AXX3JD",
- "title": "The political economy of d/acc",
- "description": "The dynamics behind d/acc are not new. Economic history is full of examples of the private provision of public goods. If we want to reduce AI risks while preserving freedom from centralized control, it's worth thinking carefully about the different ways humans have solved isomorphic problems in the past, and how the same tools could apply today.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "id": "the-rise-of-ai-in-web3-development-ux",
+ "sourceId": "LTEX8X",
+ "title": "The Rise of AI in Web3 Development UX",
+ "description": "This talk explores the intersection of artificial intelligence and Web3 technologies, highlighting how AI can enhance the development of decentralized applications and blockchain ecosystems. The presentation will provide practical examples, code snippets, and insights into Web3 AI through the lens of the recent RemixAI integration into the Remix toolset. Attendees will gain valuable knowledge on leveraging AI to build more robust, intelligent, and user-friendly decentralized applications.",
+ "track": "Usability",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "d/acc"
+ "AI Web3",
+ "LLM",
+ "Code Generation"
],
"tags": [
- "Public",
- "good"
+ "Tooling",
+ "User Experience",
+ "UI/UX",
+ "coding",
+ "generation",
+ "Tooling",
+ "UI/UX",
+ "User Experience"
],
"language": "en",
"speakers": [
- "eli-dourado"
+ "stephane-tetsing"
],
"eventId": "devcon-7",
- "slot_start": 1731553800000,
- "slot_end": 1731555000000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1Ark5gHHkzTiHgbw7rdgfM5t6pIra-jjXvX-Qq1FPlRk"
+ "slot_start": 1731565200000,
+ "slot_end": 1731565800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1zhCIin-EiFLgd3IrIQYnzWKZ4MmkJfeVVaweIJV7Mm0"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
6,
0,
@@ -761605,7 +759997,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -762044,6 +760435,23 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -762138,7 +760546,12 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
0,
+ 2,
0,
0,
0,
@@ -762176,6 +760589,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -762625,6 +761039,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -762659,40 +761075,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -762713,12 +761095,12 @@
0,
2,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -762731,39 +761113,49 @@
},
{
"session": {
- "id": "the-rated-list",
- "sourceId": "QNYDCR",
- "title": "The Rated List",
- "description": "The Rated List construction aims to minimise the number of requests required to complete sampling in Data Availability Sampling (DAS) for Ethereum. This optimisation becomes especially critical in the context of Full DAS, as data production per slot is anticipated to far exceed the current Deneb-Cancun (Dencun) specifications. The Rated List attempts to improve rate of successful sampling against unfavourable network conditions there by reducing the bandwidth consumption of the overall network.",
- "track": "[CLS] EPF Day",
- "type": "Lightning Talk",
+ "id": "the-rise-of-appchains-from-l2s-to-rollup-clusters",
+ "sourceId": "SEARYQ",
+ "title": "The rise of Appchains: from L2s to Rollup Clusters",
+ "description": "Ethereum's rollup-centric approach has led to the emergence of L2 Rollup Clusters reducing fees but creating fragmented liquidity and a less seamless user experience. Third-party bridges, though helpful, are cumbersome, vulnerable to hacks ($2B losses to date), and costly, leading to high fees. In this keynote, Alex will discuss how native interoperability, with ZK at its core, can resolve fragmentation, enabling Clusters to collaborate instead of competing for users and liquidity, ultimately dr",
+ "track": "Layer 2",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"tags": [
- "DAS",
- "Data Availability"
+ "Ethereum Roadmap",
+ "Appchains",
+ "Zero-Knowledge",
+ "interoperability",
+ "Appchains",
+ "Ethereum Roadmap",
+ "Zero-Knowledge"
],
- "keywords": [],
- "duration": 1052,
+ "keywords": [
+ "Fragmentation",
+ "UX",
+ "interoperability",
+ "Rollup Clusters",
+ "L2"
+ ],
+ "duration": 1508,
"language": "en",
"sources_swarmHash": "",
- "sources_youtubeId": "JcP2aVy1Cjc",
+ "sources_youtubeId": "Xeb_-207C_g",
"sources_ipfsHash": "",
"sources_livepeerId": "",
- "sources_streamethId": "6734828d9dbb7a90e1dd808a",
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734828d9dbb7a90e1dd808a.vtt",
- "transcript_text": " . Hello, guys. Thank you for coming for the presentation. Okay. I think I . So we are presenting the Rated List. We were mentored by Dankrad on this project. It was his idea originally. What we did was to formally specify the rated list, take it out from a blog, and have a proper set of Pythonic specs for the rated list, build a simulator against which we can test the rated list, write some unit tests so that we have some basic sanity checks test the rated list, write some unit tests so that we have some basic sanity checks of the rated list so that it does not perform worse than just randomly pure sampling, and collect some metrics against known attacks on existing DHTs. So just to give you a quick intro to rated list. Sorry. So, this was the idea proposed by Dankrad, which is instead of having a DST, you form a tree of all the nodes that you know. You ask for, in kind of a peer exchange manner, you ask for nodes of the nodes, and you build out a tree, and you start your peer sampling. based on the peer sampling if a node replies or does not reply you propagate those scores back to all the ancestors right so as you can see the red node is malicious node or a node that does not respond and because of that the scores of its direct parent and its Great-grandparents are affected So this is the basic idea of the rated list This was what was defined in the blog. We went on to further define how you would use filtering over it which is Sorry scoring. Yeah, so once you have every node's descendant score, so if a set of nodes are serving a sample, their descendant scores are not the actual scores that we use for filtering. What we do is we trickle, not trickle basically, but we kind of follow the paths of that node existence in all the subtrees because a node has many peers and it would exist in different subtrees. We take the level one peers scores, which are the best for that node's path, right? So it's the best path score of that node. We use that score, we filter out using a threshold. If the threshold does not work, like if it does not filter out any nodes, we switch to an average score for the same. And basically because we want to complete sampling even though we cannot filter out using the rated list. So that's average filtering. And after filtering, we can apply different querying strategies, which is we can use random querying strategy, we can use the highest score first, we can use the lowest score first, and we can use the average score first. Average score first and lowest score first does not make a lot of sense in the start, but if you think about it, parent node can have a perfect score because none of its children are contacted yet, right? A parent node can have a perfect score because none of its children are contacted yet. So a higher score first wouldn't be the most successful strategy in some cases. You would want to go for the average score because you know that there are some honest nodes balancing out the malicious nodes in that subtree. So there are different squaring strategies that you can apply. And for the rated list, we have defined a default score of 1.0, which is the perfect score. Which is slightly optimistic, but it's fine. Because we do scoring on a per-slot basis. So for every slot, we get all the peers, off-peers, and build a tree, and we start scoring. And we delete the scores for the next slot. We start again, right? Ideally, what we could do is we could propagate these scores into the Gossip Score V1.2 to persist over slots. So we could have that kind of a scoring mechanism as well. Why do we use the rated list, right? The main attack that we are going towards is to defend against a local key space flooding attack through Sybil nodes. We also want to reduce the amount of requests that we sent out for actually completing peer sampling which can be avoided if we can defunct an entire subtree of malicious nodes. I would say that the per-slot tempo matches very nicely with the pure sampling requirements because you can have honest acting malicious nodes, which is default on one particular block. So the entire objective is to complete sampling for that particular slot. honest acting malicious nodes, which is default on one particular block, right? So the entire objective is to complete sampling for that particular slot. So a per-slot sampling sets the tempo right. And lastly, it removes dead subtrees. So if there are any inactive nodes, they would already be removed. And you could assume that we reach a global stability point, like where everyone removes their defunct subtrees. So then coming to the simulator and the simulator's design, we had to play around a lot because for graphs, there are libraries out there, but the ones that are usually used are not that optimized. So we started with the NetworkX library, but it was really slow at generating a random graph with a high degree at number of nodes at 10,000. Right now for all our simulations, we use the degree at 50 and the number of nodes at 10,000, which is like a good assumption for a peer-to-peer sampling network, right? And we use RushWorkX because, as you can see, the benchmarks for graph generation is just the best for all the libraries that are there out there right now. And for querying strategy, we used all four querying strategies, highest, average, lowest, and actually random as well. But we also refilter nodes with a different threshold if we cannot complete sampling, because our objective is to complete sampling at the end of the day. So coming into the architecture of the simulator a little bit, we wanted to modularize everything so that this simulator can practically be used for other kinds of implementations like the rated list in the future. So having it modularized gives you an attack framework because we have written a lot of attacks right now. So you could test against these in the future. So yeah, everything's modularized. We spec convert the rated list spec into a Notepad implementation for all the simulations. I'll give it to Openana. So yeah, that's the simulator. Let me just quickly, I said it's not working. I think it's working. Okay. I mean, just since the slides are off, let's turn the attacks on, I guess. So yeah, I'll quickly brief you guys about the sort of attacks we try to use against our construction. Okay. Yeah. So basically what we try to do is poison the entire network with a lot of randomly picked nodes and mark them as malicious. The only problem with that is that the conditional probability of finding the parent being malicious with the children is almost same as just randomly picking any malicious node from the network. So just randomly marking any node doesn't make sense, and there's not a lot of difference because of the rated list. Although the only attack vector that might cause an issue would be basically trying to attack on one local key space, and that's what we tried to simulate. So yeah, basically trying to mark and enter a subtree to a malicious node, which then gave us the results where we were getting far more better results in terms of rated lists as compared to just randomly. Yeah. There you go. Okay. So yeah, there's a graph plot where we get to see where the rated list performs much better than just randomly picking out nodes and trying to sample. It's in terms of the number of requests that go out. Like for 90 percent of, 70 percent of civil nodes gives us almost double number of requests when doing a random sampling. But in case of a greater list, it's like the lower number. So is it? Okay. Okay. Got it. Okay. Yeah. So there are graphs showing those results and that there's some future work that needs to be done. We are currently researching on this new topic of trying to score the pens in a probabilistic way. Right now, it's just averaging out. So we are trying to take the probabilities of each and every children nodes and then finding the score for the parent based on those scoring for the children. So yeah, that's the scoring mechanism we are trying to work on. And I mean, oh yeah, awesome. So yeah, this is what I was talking about, where we were just randomly poisoning the nodes in the network. You don't really see a massive difference between rated list on and off. So as you can see, there's not a lot of difference, but there's a small difference. But still, this is where we shine, is the rated list performs much better than just randomly sampling from the network in case of 90 percent poisoning. So this is where there was a entire subtree marked as malicious. I think I have a small, yeah. So those are the sort of future work we are trying to do is that, since our implementation is still in like super native like primitive stage right now, so we would like to implement a better simulator. Yeah, I think this probably sums up. Yeah. Yeah. So can you go back to the graph? So just want to point out that all these graphs were done over like 100 runs at different thresholds. Sorry. So all these metrics were plotted over 100 runs with different thresholds and different strategies straight out. And for the rated list, we picked the best score among all different strategies. So best score first, average score first, and everything. Where the rated list off is just plain old naive, randomly sampling from the network. Probably just for visualization, this is the graph that the big blue ball is basically a network, but then it's all pulled out and those are the malicious nodes here. So yeah,, guys. Any questions for these two on the rated list project? Just trying to understand the Sybil graph that you had. You injected lots of Sybil nodes into the tree. And how do you determine which ones were Sybil and which ones weren't? Or have I misunderstood? Are you asking about the implementation detail? No, kind of in general. So a Sybil node would basically not reply for any peer sampling requests coming to it. We can definitely test for more cases where the attacks are more nuanced, as in the adversary can be adaptive, where the Sibyl node only responds to a certain number of nodes but not other nodes. If you want to actually eclipse a particular node, you would flood its local space and not just reply to that particular node, but reply to every other node. So you were detecting the Sybil, you didn't just assume that they were Sybil, right? You didn't just say these ones are malicious, you actually based on their responses, you determined that they were Sybil attacks. Yes. The parent-child relationship that you showed in the graph, how do you come up with the peer parent-child relationship? Is it like if this peer told you about the other peer, then it's child? Yes. So it's much more of a local view rather than a global view, where it's basically just like peer exchange where we just ask for peers from particular node. So first I ask from the nodes that I'm connected to for their peers, and then I make a list of those peers and ask for peers from them as well. I can cap this. Basically, in the rated list, we have it capped at 100 max children per node. So any node could randomly send for every slot, randomly or maybe probabilistically send a certain set of 100 nodes to us. Is this a candidate for replacing CAD-based discovery? It wouldn't replace CAD-based discovery per se. So rated list assumes that you already have a libP2P network. And for discovery, it's not really... You would need bootstrap nodes to actually form this thing, so it becomes a little more complicated over there. But what we are definitely planning on is, like if you think about it, per slot scores, they make sense if you assume that malicious nodes are honest acting until that slot, but then you can also have malicious nodes that start acting honest after that slot, and a per slot score wouldn't really help at that point. But the good thing is the version 1.2 Gossip scoring provides these application scores that you can inject into them, and they are persisted with DK parameters and everything. So we plan on just injecting the rated list score into the Gossip v1.2 scoring. All right, thank you. Let's give it up for these guys one more time.",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673498739dbb7a90e1d3f53f.vtt",
+ "transcript_text": " Hello everyone, my name is Alex, I'm the founder of ZK-Sync and CEO of Matterlabs, and today I'm going to talk about the app chains and how roll-up clusters work, what they are and what implications they have. And I will start with the, you know, it's probably obvious, roll-up centric roadmap has led to transformation of the Ethereum's original vision of the world computer into the Internet of Chains, which is not a coincidence. This is like we're in blockchain web 3.0. We're kind of following the evolution of computing in general and the evolution of the internet. It's the third wave where we're putting value and putting valuable state and global cooperation to the ultimate degree on the internet, on chain. And what it is going to lead to is that the apps will also transform uh just like the applications on the internet got their own servers and got their own functionality moving from shared co-located uh environments uh the same thing is going to happen with app chains, with applications on Ethereum. There are many reasons for this, but basically we're going to go from a world of every application is deploying on a separate chain, on all of the chains, to a world where you can deploy in one chain. It might be a chain you fully control as an application. And then all the other chains are interacting together and have access to what you're doing. And we see a lot of interest for this topic from the app builders because obviously developer experience of deploying many chains is not great. But more importantly, because you can customize your application and you can offer functions that are not possible on the uniform, like one-size-fits-all environment. And also, very importantly, you have the full ownership of what's happening there you can control the access rights you can control how you handle different policies and then you can control the value flow of the application to a much higher degree for example you can have validators who are receiving the the fees uh certain other value capturing mechanisms, and then delegating this to the token holders, to the larger community of this app. So there are many very, very strong incentives. And the main blocker, why we have not seen this happening so far, is the lack of native interop. It's not even the lack of infrastructure. The infrastructure is there. We have roll-up as a service provider. You see now hundreds of roll-ups being built, but many of them application-specific, kind of like in their infancy. Many of them are generalized, but the cost of running your own chain is approaching negligible thresholds and like you basically get a lot of services everything is is coming out of the box available for you to use but the lack of native interop is really preventing us to to live this vision through uh fully and i want to give you an intuition why and then i want to walk you through the technical trade-offs of different approaches of how we can actually make this work. So this talk is mostly for application builders and chain builders, and those application builders specifically who are considering doing their own app chain. What is the perfect world? Whenever we build a revolutionary technology, the best approach is to imagine the perfection, the perfect endgame, and then reverse engineer from there and see what steps we need to follow to get there. A perfect user experience, in our opinion, consists of three major pillars. Pillar number one is you want to have a single account. Just like today on the internet, we got to a maturity where you have your email and it's basically controlling everything you're doing on the internet, all of your accounts. And it's really easy to connect. You basically have Gmail connect, Apple connect, one click, unlocks everything. We need to get to the same experience on Ethereum. Your single wallet, you don't have to maintain a plethora of wallets on all different chains and manage their complexities. It should be very, very easy. The second thing is, from this one account, you should be able to interact with any app on all of these chains that comprise the internet of chains that is today ethereum which means no manual bridging no manual switching of networks uh and the confirmations are fast so the same user experiences you have on a single chain should happen across multiple chains. And finally, there should be no overhead involved with these interactions. When you interact, when you transact from one chain, from your account to one chain to some application, you should not be thinking about like, oh, that's going to cost me some percentage of the capital or assets that I'm sending there because there is some bridging involved and you should know that your security model should remain the same like if an app is deployed on the ZK roll-up and it's immutable smart contract you can firmly count on it because the theorem gives you this hardness and enforces its commitments and this should not be violated by some new intermediaries that are jumping in between and facilitating your bridging. So those three things must be held intact. And there are basically two ways to get there. As you probably know from the product world, we can try to come to a perfection at the Ethereum white level, like have endless conversations, think through, go through endless iterations and come with the perfect design and try to implement this, which will probably take 10 years. Or we can go through a gradual path and deliver incremental value as we go. And obviously, you can imagine which way I'm advocating for. Ethereum has always been pragmatic and embraced the second approach. So what would the second approach look like for Pan-Ethereum interop that can enable the rise of the AppChains? The first level,",
"eventId": "devcon-7",
- "slot_start": 1731486600000,
- "slot_end": 1731487500000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1tvKSVVMilC4YJnTAe-LSaWUsQBBm9OaP3zYQYmWuVJ4",
+ "slot_start": 1731493800000,
+ "slot_end": 1731495600000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1WOJXGXgVk5LDrCpMtULqypFYqyEzI5whhM4XbIRAcVA",
"resources_slides": null,
"speakers": [
- "chirag-mahaveer-parmar",
- "hopinheimer"
+ "alex-gluchowski"
]
},
"vector": [
@@ -762774,6 +761166,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -762782,7 +761175,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -763423,11 +761815,6 @@
0,
0,
6,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -763533,6 +761920,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -763586,7 +761974,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -763713,6 +762100,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -763848,6 +762236,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -763874,7 +762263,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -763911,6 +762299,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -764084,7 +762473,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -764097,42 +762485,47 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "the-ripple-effect-of-devcon-vi",
- "sourceId": "E3U3XU",
- "title": "The Ripple Effect of Devcon VI",
- "description": "Devcon VI in Bogotá accelerated community growth across the region. Local communities emerged in several cities in Colombia and Latin America. The gathering provided leaders with a new perspective on enhancing collective creation for social impact and blockchain adoption. At ETH Bogotá, we used this spark to transition from hosting general events to creating an educational system for developers and builders, aiming to push the adoption of blockchain and Ethereum in a new way.",
+ "id": "the-role-of-culture-in-shaping-technology-the-case-for-cuteacc",
+ "sourceId": "LRJTXY",
+ "title": "The role of culture in shaping technology - the case for cute/acc",
+ "description": "Who builds technology and for whom? In decentralized technology, we must apply the cypherpunk ethos not only to the product we want to provide to the world but also to the manner we build that product. We must avoid imposing our worldview onto different cultures, or we risk reinventing tech neocolonialism. This talk will illustrate the risks of concentration of power and tech within our industry into the hands of a few cultures and present ways to build a truly cypherpunk future.",
"track": "Real World Ethereum",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Education"
+ "Philosophy",
+ "Diversity",
+ "Democracy"
],
"tags": [
- "Vision",
- "Ethereum for Good",
- "Local Impact",
- "education",
- "Ethereum for Good",
- "Local Impact",
- "Vision"
+ "Network State",
+ "Digital Sovereignty",
+ "Decentralization",
+ "diversity",
+ "democracy",
+ "philosophy",
+ "Decentralization",
+ "Digital Sovereignty",
+ "Network State"
],
"language": "en",
"speakers": [
- "julio-cesar-arango"
+ "fatemeh-fannizadeh"
],
"eventId": "devcon-7",
- "slot_start": 1731559800000,
- "slot_end": 1731560400000,
+ "slot_start": 1731560400000,
+ "slot_end": 1731561000000,
"slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1vrrnCLaeOKKIwa7Mc_RpUOzo-jB1B7QzDNcIzCEOrak"
+ "resources_presentation": "https://docs.google.com/presentation/d/1Wi0ob1KXq6nswjq25vU56mNvitsmnOnrWaRe-gSp-3k"
},
"vector": [
0,
@@ -764748,6 +763141,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -764792,8 +763186,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -764932,8 +763324,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -764978,7 +763372,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -764986,6 +763379,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -765121,16 +763515,10 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -765400,6 +763788,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -765454,10 +763844,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -765470,40 +763860,40 @@
},
{
"session": {
- "id": "the-rise-of-ai-in-web3-development-ux",
- "sourceId": "LTEX8X",
- "title": "The Rise of AI in Web3 Development UX",
- "description": "This talk explores the intersection of artificial intelligence and Web3 technologies, highlighting how AI can enhance the development of decentralized applications and blockchain ecosystems. The presentation will provide practical examples, code snippets, and insights into Web3 AI through the lens of the recent RemixAI integration into the Remix toolset. Attendees will gain valuable knowledge on leveraging AI to build more robust, intelligent, and user-friendly decentralized applications.",
- "track": "Usability",
- "type": "Lightning Talk",
+ "id": "the-shape-of-protocols-to-come",
+ "sourceId": "TYGBPN",
+ "title": "The Shape of Protocols to Come",
+ "description": "Ethereum defies easy categorization—it blends aspects of money, nations, and more, yet doesn't fit neatly into any single category. To build better mental models for understanding Ethereum, we've spent the past two years stepping back and exploring the broader class it belongs to: Protocols. This talk explores the fundamental properties of protocols, strategies for navigating them, and how Ethereum can uniquely contribute to this emerging research field.",
+ "track": "Coordination",
+ "type": "Talk",
"expertise": "Beginner",
"audience": "Engineering",
- "featured": false,
+ "featured": true,
"doNotRecord": false,
- "keywords": [
- "AI Web3",
- "LLM",
- "Code Generation"
- ],
"tags": [
- "Tooling",
- "User Experience",
- "UI/UX",
- "coding",
- "generation",
- "Tooling",
- "UI/UX",
- "User Experience"
+ "Ethereum Roadmap",
+ "Protocol Design",
+ "Use Cases"
],
+ "keywords": [],
+ "duration": 1402,
"language": "en",
- "speakers": [
- "stephane-tetsing"
- ],
+ "sources_swarmHash": "43b3f1b06406e849ea5082a4989e38e5f86d942069ea888dc8d826cab53670a5",
+ "sources_youtubeId": "t_2ZIfF9gMc",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731565200000,
- "slot_end": 1731565800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1zhCIin-EiFLgd3IrIQYnzWKZ4MmkJfeVVaweIJV7Mm0"
+ "slot_start": 1731409200000,
+ "slot_end": 1731411000000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/15QhPTXl4SBVPn-h9srUsdXijj_OIaZYVL1C32DxEyiw",
+ "resources_slides": null,
+ "speakers": [
+ "tim-beiko"
+ ]
},
"vector": [
0,
@@ -765514,6 +763904,9 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
6,
0,
0,
@@ -765688,6 +764081,15 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -766164,7 +764566,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -766274,12 +764675,10 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -766292,6 +764691,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -766430,6 +764837,30 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -766770,50 +765201,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -766841,63 +765228,45 @@
},
{
"session": {
- "id": "the-rise-of-appchains-from-l2s-to-rollup-clusters",
- "sourceId": "SEARYQ",
- "title": "The rise of Appchains: from L2s to Rollup Clusters",
- "description": "Ethereum's rollup-centric approach has led to the emergence of L2 Rollup Clusters reducing fees but creating fragmented liquidity and a less seamless user experience. Third-party bridges, though helpful, are cumbersome, vulnerable to hacks ($2B losses to date), and costly, leading to high fees. In this keynote, Alex will discuss how native interoperability, with ZK at its core, can resolve fragmentation, enabling Clusters to collaborate instead of competing for users and liquidity, ultimately dr",
- "track": "Layer 2",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "the-silicon-hospital-and-a-new-way-to-make-medical-devices",
+ "sourceId": "D8UTDS",
+ "title": "The Silicon Hospital and a New Way to Make Medical Devices",
+ "description": "Could silicon be more effective for medical treatment than drugs someday? We think that day could be soon. Openwater has spent nearly 9 years developing new tech to treat a range of diseases. It's not pulse ox, fNIRs, HIFU or EEG ... it's new hard tech and it's open-source. We will demo the tech on stage, and share with you our clinical results to date and explain how the technology works. We expect to be in over 100 clinical trials next year.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Ethereum Roadmap",
- "Appchains",
- "Zero-Knowledge",
- "interoperability",
- "Appchains",
- "Ethereum Roadmap",
- "Zero-Knowledge"
- ],
"keywords": [
- "Fragmentation",
- "UX",
- "interoperability",
- "Rollup Clusters",
- "L2"
+ "Healthcare",
+ "",
+ "Medical"
+ ],
+ "tags": [
+ "DeSci",
+ "Open Source Software",
+ "Scalability"
],
- "duration": 1508,
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "Xeb_-207C_g",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673498739dbb7a90e1d3f53f.vtt",
- "transcript_text": " Hello everyone, my name is Alex, I'm the founder of ZK-Sync and CEO of Matterlabs, and today I'm going to talk about the app chains and how roll-up clusters work, what they are and what implications they have. And I will start with the, you know, it's probably obvious, roll-up centric roadmap has led to transformation of the Ethereum's original vision of the world computer into the Internet of Chains, which is not a coincidence. This is like we're in blockchain web 3.0. We're kind of following the evolution of computing in general and the evolution of the internet. It's the third wave where we're putting value and putting valuable state and global cooperation to the ultimate degree on the internet, on chain. And what it is going to lead to is that the apps will also transform uh just like the applications on the internet got their own servers and got their own functionality moving from shared co-located uh environments uh the same thing is going to happen with app chains, with applications on Ethereum. There are many reasons for this, but basically we're going to go from a world of every application is deploying on a separate chain, on all of the chains, to a world where you can deploy in one chain. It might be a chain you fully control as an application. And then all the other chains are interacting together and have access to what you're doing. And we see a lot of interest for this topic from the app builders because obviously developer experience of deploying many chains is not great. But more importantly, because you can customize your application and you can offer functions that are not possible on the uniform, like one-size-fits-all environment. And also, very importantly, you have the full ownership of what's happening there you can control the access rights you can control how you handle different policies and then you can control the value flow of the application to a much higher degree for example you can have validators who are receiving the the fees uh certain other value capturing mechanisms, and then delegating this to the token holders, to the larger community of this app. So there are many very, very strong incentives. And the main blocker, why we have not seen this happening so far, is the lack of native interop. It's not even the lack of infrastructure. The infrastructure is there. We have roll-up as a service provider. You see now hundreds of roll-ups being built, but many of them application-specific, kind of like in their infancy. Many of them are generalized, but the cost of running your own chain is approaching negligible thresholds and like you basically get a lot of services everything is is coming out of the box available for you to use but the lack of native interop is really preventing us to to live this vision through uh fully and i want to give you an intuition why and then i want to walk you through the technical trade-offs of different approaches of how we can actually make this work. So this talk is mostly for application builders and chain builders, and those application builders specifically who are considering doing their own app chain. What is the perfect world? Whenever we build a revolutionary technology, the best approach is to imagine the perfection, the perfect endgame, and then reverse engineer from there and see what steps we need to follow to get there. A perfect user experience, in our opinion, consists of three major pillars. Pillar number one is you want to have a single account. Just like today on the internet, we got to a maturity where you have your email and it's basically controlling everything you're doing on the internet, all of your accounts. And it's really easy to connect. You basically have Gmail connect, Apple connect, one click, unlocks everything. We need to get to the same experience on Ethereum. Your single wallet, you don't have to maintain a plethora of wallets on all different chains and manage their complexities. It should be very, very easy. The second thing is, from this one account, you should be able to interact with any app on all of these chains that comprise the internet of chains that is today ethereum which means no manual bridging no manual switching of networks uh and the confirmations are fast so the same user experiences you have on a single chain should happen across multiple chains. And finally, there should be no overhead involved with these interactions. When you interact, when you transact from one chain, from your account to one chain to some application, you should not be thinking about like, oh, that's going to cost me some percentage of the capital or assets that I'm sending there because there is some bridging involved and you should know that your security model should remain the same like if an app is deployed on the ZK roll-up and it's immutable smart contract you can firmly count on it because the theorem gives you this hardness and enforces its commitments and this should not be violated by some new intermediaries that are jumping in between and facilitating your bridging. So those three things must be held intact. And there are basically two ways to get there. As you probably know from the product world, we can try to come to a perfection at the Ethereum white level, like have endless conversations, think through, go through endless iterations and come with the perfect design and try to implement this, which will probably take 10 years. Or we can go through a gradual path and deliver incremental value as we go. And obviously, you can imagine which way I'm advocating for. Ethereum has always been pragmatic and embraced the second approach. So what would the second approach look like for Pan-Ethereum interop that can enable the rise of the AppChains? The first level,",
- "eventId": "devcon-7",
- "slot_start": 1731493800000,
- "slot_end": 1731495600000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1WOJXGXgVk5LDrCpMtULqypFYqyEzI5whhM4XbIRAcVA",
- "resources_slides": null,
"speakers": [
- "alex-gluchowski"
- ]
+ "mary-lou-jepsen"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731574200000,
+ "slot_end": 1731575100000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1cscUxEQdkm5QVkLDeEDz09MWGMPqPDhGH5xZlEf1yRQ"
},
"vector": [
0,
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -767651,7 +766020,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -767738,6 +766106,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -767773,11 +766142,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -767831,7 +766202,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -767968,7 +766338,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -768031,7 +766400,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -768200,7 +766568,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -768211,6 +766578,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -768222,41 +766591,44 @@
},
{
"session": {
- "id": "the-role-of-culture-in-shaping-technology-the-case-for-cuteacc",
- "sourceId": "LRJTXY",
- "title": "The role of culture in shaping technology - the case for cute/acc",
- "description": "Who builds technology and for whom? In decentralized technology, we must apply the cypherpunk ethos not only to the product we want to provide to the world but also to the manner we build that product. We must avoid imposing our worldview onto different cultures, or we risk reinventing tech neocolonialism. This talk will illustrate the risks of concentration of power and tech within our industry into the hands of a few cultures and present ways to build a truly cypherpunk future.",
- "track": "Real World Ethereum",
+ "id": "the-state-of-web3-support-today-what-just-happened",
+ "sourceId": "BZRKUD",
+ "title": "The State of Web3 Support Today: What Just Happened?",
+ "description": "One of the most common and painful experiences someone can have today is also one of the most fundamental concepts we tend to take for granted - transactions. Users who seek support for their issues lack the appropriate level of information to even understand what they were doing when it all went wrong. This talk will examine why core web3 experiences are still problematic and propose things to consider when building experiences for everyone that ranges from in app UX to community support tools.",
+ "track": "Usability",
"type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Developer",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Philosophy",
- "Diversity",
- "Democracy"
- ],
"tags": [
- "Network State",
- "Digital Sovereignty",
- "Decentralization",
- "diversity",
- "democracy",
- "philosophy",
- "Decentralization",
- "Digital Sovereignty",
- "Network State"
+ "community",
+ "Accessibility",
+ "Tooling",
+ "User Experience"
],
- "language": "en",
- "speakers": [
- "fatemeh-fannizadeh"
+ "keywords": [
+ "User Support",
+ "Community"
],
+ "duration": 304,
+ "language": "en",
+ "sources_swarmHash": "fb6714e3f29aebfbf0c0287d93a797c37483f8f4909ffb6478031e93712229e4",
+ "sources_youtubeId": "sur3bRJQw-U",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731560400000,
- "slot_end": 1731561000000,
+ "slot_start": 1731408600000,
+ "slot_end": 1731409200000,
"slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1Wi0ob1KXq6nswjq25vU56mNvitsmnOnrWaRe-gSp-3k"
+ "resources_presentation": "https://docs.google.com/presentation/d/1jmtrpYtos5-qZy0sfliSMlhtQfUi9JSCAcTEP4C554k",
+ "resources_slides": null,
+ "speakers": [
+ "fungible-taco"
+ ]
},
"vector": [
0,
@@ -768265,10 +766637,9 @@
0,
0,
0,
- 6,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -768877,7 +767248,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -768918,6 +767288,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -769025,10 +767396,12 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -769058,10 +767431,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -769069,6 +767440,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -769113,7 +767485,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -769141,7 +767512,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -769186,6 +767556,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -769525,8 +767896,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -769578,9 +767947,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -769594,40 +767963,38 @@
},
{
"session": {
- "id": "the-shape-of-protocols-to-come",
- "sourceId": "TYGBPN",
- "title": "The Shape of Protocols to Come",
- "description": "Ethereum defies easy categorization—it blends aspects of money, nations, and more, yet doesn't fit neatly into any single category. To build better mental models for understanding Ethereum, we've spent the past two years stepping back and exploring the broader class it belongs to: Protocols. This talk explores the fundamental properties of protocols, strategies for navigating them, and how Ethereum can uniquely contribute to this emerging research field.",
- "track": "Coordination",
+ "id": "the-supreme-ruler-of-the-world",
+ "sourceId": "TLWWCW",
+ "title": "The Supreme Ruler of the World",
+ "description": "VK rules the world. ZK rules the world, too, like a straightedge wielded with eyes closed. Rulers rule in simple ways: by lining things up and by checking they're all in line. Bring your high school math to learn straightedges called SumCheck and SumCalc and begin to appreciate ZK in simple geometric terms. No moon math. We'll visit lines, cubes and polynomials, to see how they can be used to deduce and to generate, to check and to delegate.",
+ "track": "Applied Cryptography",
"type": "Talk",
"expertise": "Beginner",
"audience": "Engineering",
- "featured": true,
+ "featured": false,
"doNotRecord": false,
+ "keywords": [
+ "sumcalc",
+ "sumcheck"
+ ],
"tags": [
- "Ethereum Roadmap",
- "Protocol Design",
- "Use Cases"
+ "Scalability",
+ "Validiums",
+ "Zero-Knowledge",
+ "sumcheck",
+ "Scalability",
+ "Validiums",
+ "Zero-Knowledge"
],
- "keywords": [],
- "duration": 1402,
"language": "en",
- "sources_swarmHash": "43b3f1b06406e849ea5082a4989e38e5f86d942069ea888dc8d826cab53670a5",
- "sources_youtubeId": "t_2ZIfF9gMc",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731409200000,
- "slot_end": 1731411000000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/15QhPTXl4SBVPn-h9srUsdXijj_OIaZYVL1C32DxEyiw",
- "resources_slides": null,
"speakers": [
- "tim-beiko"
- ]
+ "don-beaver"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731484800000,
+ "slot_end": 1731486600000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1IP5PshRsU2LlH33ndPmkTGZJki3mzS-uZ3M-Yc5vD6o"
},
"vector": [
0,
@@ -769640,7 +768007,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -769816,13 +768182,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -770296,6 +768655,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -770398,6 +768758,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -770428,7 +768789,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -770461,7 +768821,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -770527,6 +768886,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -770574,7 +768934,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -770837,6 +769196,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -770899,6 +769259,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -770965,37 +769329,42 @@
},
{
"session": {
- "id": "the-silicon-hospital-and-a-new-way-to-make-medical-devices",
- "sourceId": "D8UTDS",
- "title": "The Silicon Hospital and a New Way to Make Medical Devices",
- "description": "Could silicon be more effective for medical treatment than drugs someday? We think that day could be soon. Openwater has spent nearly 9 years developing new tech to treat a range of diseases. It's not pulse ox, fNIRs, HIFU or EEG ... it's new hard tech and it's open-source. We will demo the tech on stage, and share with you our clinical results to date and explain how the technology works. We expect to be in over 100 clinical trials next year.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "the-tension-between-mev-and-censorship-resistance-gadgets",
+ "sourceId": "G3MBF7",
+ "title": "The tension between MEV and Censorship Resistance Gadgets",
+ "description": "Although fairly unrelated at first glance, MEV is currently *the* bottleneck for a censorship-resistant Ethereum. This talk will first explore why MEV and censorship resistance are fundamentally counterforces. Then, we will dive into how MEV constrains the design space of censorship-resistant gadgets like Inclusion Lists and Concurrent Block Producers. What does the future of censorship resistance look like for Ethereum?",
+ "track": "Cryptoeconomics",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Healthcare",
- "",
- "Medical"
+ "Inclusion Lists",
+ "Protocol Design"
],
"tags": [
- "DeSci",
- "Open Source Software",
- "Scalability"
+ "Ethereum Roadmap",
+ "Censorship Resistance",
+ "Design",
+ "MEV",
+ "protocol",
+ "Censorship Resistance",
+ "Ethereum Roadmap",
+ "MEV"
],
"language": "en",
"speakers": [
- "mary-lou-jepsen"
+ "julian-ma"
],
"eventId": "devcon-7",
- "slot_start": 1731574200000,
- "slot_end": 1731575100000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1cscUxEQdkm5QVkLDeEDz09MWGMPqPDhGH5xZlEf1yRQ"
+ "slot_start": 1731641400000,
+ "slot_end": 1731643200000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1q6BQXCGubElt47T2cCMmisWZixsWRezzeO8I3FiONPU"
},
"vector": [
+ 0,
0,
6,
0,
@@ -771604,6 +769973,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -771656,7 +770026,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -771746,6 +770115,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -771846,7 +770216,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -771882,7 +770251,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -771893,6 +770261,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -771936,6 +770305,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -772133,11 +770503,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -772313,13 +770679,12 @@
0,
2,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -772331,44 +770696,37 @@
},
{
"session": {
- "id": "the-state-of-web3-support-today-what-just-happened",
- "sourceId": "BZRKUD",
- "title": "The State of Web3 Support Today: What Just Happened?",
- "description": "One of the most common and painful experiences someone can have today is also one of the most fundamental concepts we tend to take for granted - transactions. Users who seek support for their issues lack the appropriate level of information to even understand what they were doing when it all went wrong. This talk will examine why core web3 experiences are still problematic and propose things to consider when building experiences for everyone that ranges from in app UX to community support tools.",
- "track": "Usability",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "id": "the-three-transitions-cross-chain-smart-wallets-with-privacy",
+ "sourceId": "JESAHN",
+ "title": "The Three Transitions: Cross-Chain Smart Wallets with Privacy",
+ "description": "Last year, Vitalik outlined [\"The Three Transitions\"](https://vitalik.eth.limo/general/2023/06/09/three_transitions.html) ahead for the Ethereum stack: moving to L2s, smart wallets, and private transactions. The Base team has built [Keyspace](https://docs.key.space/), a cross-chain keystore that helps all wallets makes these transitions. Come learn about how Keyspace works and how Keyspace helps smart wallets sync signers and send private transactions in a multichain world.",
+ "track": "Layer 2",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "community",
- "Accessibility",
- "Tooling",
- "User Experience"
- ],
"keywords": [
- "User Support",
- "Community"
+ "Wallets"
+ ],
+ "tags": [
+ "Zk Rollups",
+ "Cross-L2",
+ "Account Abstraction",
+ "wallet",
+ "Account Abstraction",
+ "Cross-L2",
+ "Zk Rollups"
],
- "duration": 304,
"language": "en",
- "sources_swarmHash": "fb6714e3f29aebfbf0c0287d93a797c37483f8f4909ffb6478031e93712229e4",
- "sources_youtubeId": "sur3bRJQw-U",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731408600000,
- "slot_end": 1731409200000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1jmtrpYtos5-qZy0sfliSMlhtQfUi9JSCAcTEP4C554k",
- "resources_slides": null,
"speakers": [
- "fungible-taco"
- ]
+ "niran-babalola"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731472200000,
+ "slot_end": 1731474000000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/12qgh9Oa6U7CvGBkNUiXG-L-E0qYKLqahhOhkZATUF_Q"
},
"vector": [
0,
@@ -772378,7 +770736,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -773031,7 +771388,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -773139,12 +771495,10 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -773175,6 +771529,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -773183,7 +771538,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -773193,6 +771547,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -773299,7 +771654,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -773324,6 +771678,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -773637,6 +771992,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -773683,6 +772039,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -773692,8 +772049,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -773706,38 +772061,48 @@
},
{
"session": {
- "id": "the-supreme-ruler-of-the-world",
- "sourceId": "TLWWCW",
- "title": "The Supreme Ruler of the World",
- "description": "VK rules the world. ZK rules the world, too, like a straightedge wielded with eyes closed. Rulers rule in simple ways: by lining things up and by checking they're all in line. Bring your high school math to learn straightedges called SumCheck and SumCalc and begin to appreciate ZK in simple geometric terms. No moon math. We'll visit lines, cubes and polynomials, to see how they can be used to deduce and to generate, to check and to delegate.",
- "track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Engineering",
+ "id": "the-trustless-trade-supply-chain",
+ "sourceId": "RQZADG",
+ "title": "The Trustless Trade Supply Chain",
+ "description": "Trades are fundamental to defi. Without credibly neutral trade execution – we risk the same centralisation and rent extraction through privileged actors that we have in tradfi.\r\n\r\nToday, the trade supply chain in defi is mostly centralised: Intent auctions, builders, solvers and market makers are handful of off-chain actors with privileged access.\r\n\r\nHowever, a trustless, and decentralised trade supply chain is possible. This talk highlights the current and future technologies that make it possible.",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "sumcalc",
- "sumcheck"
- ],
"tags": [
- "Scalability",
- "Validiums",
- "Zero-Knowledge",
- "sumcheck",
- "Scalability",
- "Validiums",
- "Zero-Knowledge"
+ "PBS",
+ "MEV",
+ "Trading",
+ "Intents",
+ "TEE",
+ "Intents",
+ "MEV",
+ "PBS",
+ "Trading"
],
- "language": "en",
- "speakers": [
- "don-beaver"
+ "keywords": [
+ "TEE"
],
+ "duration": 460,
+ "language": "en",
+ "sources_swarmHash": "8eddb90eeded5ff214a45d5bdf580280a4d8a2356f2f3614fcd3ea3f15d1049a",
+ "sources_youtubeId": "9EPCog8GiiQ",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333cae3a168eb535f2978c.vtt",
+ "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you",
"eventId": "devcon-7",
- "slot_start": 1731484800000,
- "slot_end": 1731486600000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1IP5PshRsU2LlH33ndPmkTGZJki3mzS-uZ3M-Yc5vD6o"
+ "slot_start": 1731410400000,
+ "slot_end": 1731411000000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ZpnW0qJAIFrezIxxeweffstYIWJbW-4Aa1uhy79go6A",
+ "resources_slides": null,
+ "speakers": [
+ "markus"
+ ]
},
"vector": [
0,
@@ -773746,13 +772111,11 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -774493,6 +772856,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -774504,8 +772868,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -774531,6 +772893,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -774546,6 +772909,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -774572,6 +772936,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -774632,7 +772997,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -774821,6 +773185,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -774945,7 +773310,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -775008,7 +773372,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -775052,10 +773415,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
2,
0,
@@ -775069,47 +773432,45 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "the-tension-between-mev-and-censorship-resistance-gadgets",
- "sourceId": "G3MBF7",
- "title": "The tension between MEV and Censorship Resistance Gadgets",
- "description": "Although fairly unrelated at first glance, MEV is currently *the* bottleneck for a censorship-resistant Ethereum. This talk will first explore why MEV and censorship resistance are fundamentally counterforces. Then, we will dive into how MEV constrains the design space of censorship-resistant gadgets like Inclusion Lists and Concurrent Block Producers. What does the future of censorship resistance look like for Ethereum?",
- "track": "Cryptoeconomics",
+ "id": "the-verge-is-not-going-to-break-your-contracts",
+ "sourceId": "NJXNE3",
+ "title": "The verge is (not) going to break your contracts!",
+ "description": "The verge is comming, and with it a new pricing model for storage. This breaks many assumption that compilers have been doing for years. We'll see how part and future contracts are going to be affected, and what design should be favored in anticipation of the verge.",
+ "track": "Developer Experience",
"type": "Talk",
"expertise": "Expert",
- "audience": "Research",
+ "audience": "Developper",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Inclusion Lists",
- "Protocol Design"
+ "compiler"
],
"tags": [
- "Ethereum Roadmap",
- "Censorship Resistance",
- "Design",
- "MEV",
- "protocol",
- "Censorship Resistance",
- "Ethereum Roadmap",
- "MEV"
+ "Verkle trees",
+ "Libraries",
+ "Best Practices",
+ "compilers",
+ "Best Practices",
+ "Libraries",
+ "Verkle trees"
],
"language": "en",
"speakers": [
- "julian-ma"
+ "hadrien-croubois"
],
"eventId": "devcon-7",
- "slot_start": 1731641400000,
- "slot_end": 1731643200000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1q6BQXCGubElt47T2cCMmisWZixsWRezzeO8I3FiONPU"
+ "slot_start": 1731492000000,
+ "slot_end": 1731493800000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1qXCj-zxWc3N3cgUT-kq17kAdjRXdLfCUoe5VGTpy0TE"
},
"vector": [
+ 0,
0,
0,
6,
@@ -775724,7 +774085,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -775759,6 +774119,9 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
0,
0,
0,
@@ -775864,14 +774227,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -775891,6 +774250,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -776005,12 +774365,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -776089,6 +774447,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -776253,8 +774612,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -776428,7 +774785,6 @@
0,
2,
0,
- 2,
0,
0,
0,
@@ -776436,6 +774792,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -776445,37 +774802,40 @@
},
{
"session": {
- "id": "the-three-transitions-cross-chain-smart-wallets-with-privacy",
- "sourceId": "JESAHN",
- "title": "The Three Transitions: Cross-Chain Smart Wallets with Privacy",
- "description": "Last year, Vitalik outlined [\"The Three Transitions\"](https://vitalik.eth.limo/general/2023/06/09/three_transitions.html) ahead for the Ethereum stack: moving to L2s, smart wallets, and private transactions. The Base team has built [Keyspace](https://docs.key.space/), a cross-chain keystore that helps all wallets makes these transitions. Come learn about how Keyspace works and how Keyspace helps smart wallets sync signers and send private transactions in a multichain world.",
- "track": "Layer 2",
+ "id": "the-verifiability-vision",
+ "sourceId": "KXRMGY",
+ "title": "The verifiability vision",
+ "description": "Imagine all data was guaranteed to be correct. We could build a trustworthy digital world based only on correct data. In this presentation, we will sketch layers and techniques that can realize this dream, in particular proof carrying data and succinct proofs. We will also discuss the connection to the proof singularity vision for Ethereum as well as highlight caveats that apply; humanity is still in the early stages of the journey and there are obstacles and constraints to tackle",
+ "track": "Applied Cryptography",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Wallets"
+ "Verifiability",
+ "proof carrying data",
+ "succinct proofs"
],
"tags": [
- "Zk Rollups",
- "Cross-L2",
- "Account Abstraction",
- "wallet",
- "Account Abstraction",
- "Cross-L2",
- "Zk Rollups"
+ "Scalability",
+ "Vision",
+ "ZKP",
+ "proof",
+ "succinct",
+ "Scalability",
+ "Vision",
+ "ZKP"
],
"language": "en",
"speakers": [
- "niran-babalola"
+ "jens-groth"
],
"eventId": "devcon-7",
- "slot_start": 1731472200000,
- "slot_end": 1731474000000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/12qgh9Oa6U7CvGBkNUiXG-L-E0qYKLqahhOhkZATUF_Q"
+ "slot_start": 1731578400000,
+ "slot_end": 1731580200000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1D13mwNG569Eo7vRzSRs1BRHF7sCXAys5mnZEJpklwtg"
},
"vector": [
0,
@@ -776485,12 +774845,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -777281,8 +775639,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -777299,7 +775655,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -777307,6 +775662,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -777371,6 +775727,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -777430,8 +775787,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -777456,6 +775811,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -777464,6 +775820,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -777657,7 +776014,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -777746,6 +776102,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -777795,8 +776152,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -777813,56 +776170,43 @@
},
{
"session": {
- "id": "the-trustless-trade-supply-chain",
- "sourceId": "RQZADG",
- "title": "The Trustless Trade Supply Chain",
- "description": "Trades are fundamental to defi. Without credibly neutral trade execution – we risk the same centralisation and rent extraction through privileged actors that we have in tradfi.\r\n\r\nToday, the trade supply chain in defi is mostly centralised: Intent auctions, builders, solvers and market makers are handful of off-chain actors with privileged access.\r\n\r\nHowever, a trustless, and decentralised trade supply chain is possible. This talk highlights the current and future technologies that make it possible.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
+ "id": "the-verkle-advantage",
+ "sourceId": "YLBEZN",
+ "title": "The verkle advantage",
+ "description": "This talk provides a comprehensive overview of the achievements by the stateless development effort, over the past year. It will explore some of the discoveries we made while implementing verkle trees, that improve the user and developer experience of Ethereum.",
+ "track": "Core Protocol",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "PBS",
- "MEV",
- "Trading",
- "Intents",
- "TEE",
- "Intents",
- "MEV",
- "PBS",
- "Trading"
- ],
"keywords": [
- "TEE"
+ "stateless"
+ ],
+ "tags": [
+ "Core Protocol",
+ "Protocol Design",
+ "Verkle trees",
+ "stateless",
+ "Core Protocol",
+ "Protocol Design",
+ "Verkle trees"
],
- "duration": 460,
"language": "en",
- "sources_swarmHash": "8eddb90eeded5ff214a45d5bdf580280a4d8a2356f2f3614fcd3ea3f15d1049a",
- "sources_youtubeId": "9EPCog8GiiQ",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333cae3a168eb535f2978c.vtt",
- "transcript_text": " Music you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you you",
- "eventId": "devcon-7",
- "slot_start": 1731410400000,
- "slot_end": 1731411000000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1ZpnW0qJAIFrezIxxeweffstYIWJbW-4Aa1uhy79go6A",
- "resources_slides": null,
"speakers": [
- "markus"
- ]
+ "guillaume-ballet"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731488400000,
+ "slot_end": 1731490200000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1zs9ePGkdyS7IfCoOeK_dArKiELQYjDXk5L-A70d7Gf4"
},
"vector": [
0,
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -778611,7 +776955,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -778628,6 +776971,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -778648,13 +776992,13 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -778664,7 +777008,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -778691,7 +777034,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -778803,6 +777145,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -778941,7 +777284,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -779126,6 +777468,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -779174,7 +777517,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -779187,44 +777529,52 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "the-verge-is-not-going-to-break-your-contracts",
- "sourceId": "NJXNE3",
- "title": "The verge is (not) going to break your contracts!",
- "description": "The verge is comming, and with it a new pricing model for storage. This breaks many assumption that compilers have been doing for years. We'll see how part and future contracts are going to be affected, and what design should be favored in anticipation of the verge.",
- "track": "Developer Experience",
+ "id": "the-wallet-and-ux-stack-to-build-web3-applications-for-the-masses",
+ "sourceId": "LCNEGW",
+ "title": "The Wallet and UX Stack to Build Web3 Applications for the Masses",
+ "description": "In this talk I will give an overview of how wallet infrastructure and the relationship between wallets and dapps have evolved over the past 5 years. And give a layer-by-layer breakdown of the modern wallet stack from signers to smart account modules, how each component contributes to a UX unlock on Ethereum/L2s, and how application developers can use them today. We will also touch on pertinent ongoing EIPs such as 7702 (deploy code for EOAs), and 7715 (permissions).",
+ "track": "Usability",
"type": "Talk",
- "expertise": "Expert",
- "audience": "Developper",
+ "expertise": "Intermediate",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
"keywords": [
- "compiler"
+ "Wallets",
+ "Signers",
+ "Permissions"
],
"tags": [
- "Verkle trees",
- "Libraries",
- "Best Practices",
- "compilers",
- "Best Practices",
- "Libraries",
- "Verkle trees"
+ "Developer Infrastructure",
+ "User Experience",
+ "Account Abstraction",
+ "permissions",
+ "Account Abstraction",
+ "Developer Infrastructure",
+ "User Experience"
],
"language": "en",
"speakers": [
- "hadrien-croubois"
+ "nichanan-kesonpat"
],
"eventId": "devcon-7",
- "slot_start": 1731492000000,
- "slot_end": 1731493800000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1qXCj-zxWc3N3cgUT-kq17kAdjRXdLfCUoe5VGTpy0TE"
+ "slot_start": 1731470400000,
+ "slot_end": 1731472200000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1EwxJbkAW9PZZpjRozkPVAnLaQpoQZm7uf1kolnUFM_0"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -779878,6 +778228,11 @@
0,
0,
0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
6,
0,
0,
@@ -779980,6 +778335,14 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -779988,7 +778351,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -780011,6 +778373,57 @@
2,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -780170,7 +778583,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -780206,7 +778618,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -780425,6 +778836,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -780468,6 +778880,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -780475,6 +778888,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -780483,12 +778897,68 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "the-wellbeing-protocol-scaling-localism",
+ "sourceId": "HC3QGN",
+ "title": "The Wellbeing Protocol - Scaling Localism",
+ "description": "Imagine a world where:\r\n - hyper-local marginalised communities could create impact DAOs as easily as creating FB groups\r\n - we could create a UI that abstracted the complexity of quadratic / conviction / delegated voting to create a continuous resource allocation alternative to governance\r\n - funders could stream money into millions of these treasuries\r\n\r\nFind out how this New Zealand government funded project, now running trials in three countries, is creating a network of grassroots changemakers.",
+ "track": "Real World Ethereum",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Community",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "conviction",
+ "zealand"
+ ],
+ "tags": [
+ "DAO",
+ "Governance",
+ "Quadratic Voting",
+ "Collective Intelligence",
+ "Conviction",
+ "Ethereum for Good",
+ "Public good",
+ "Climate",
+ "ReFi",
+ "Regenerative Applications",
+ "User Experience",
+ "zealand",
+ "Climate",
+ "Collective Intelligence",
+ "Conviction",
+ "DAO",
+ "Ethereum for Good",
+ "Governance",
+ "Public good",
+ "Quadratic Voting",
+ "ReFi",
+ "Regenerative Applications",
+ "User Experience"
+ ],
+ "language": "en",
+ "speakers": [
+ "mark-pascall"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731481200000,
+ "slot_end": 1731481800000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1RsF9WALoUv0Wv3Pc036sfCbuKskiOHZzZRM1r385Iew"
+ },
+ "vector": [
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -780541,7 +779011,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -780550,52 +779019,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "the-verifiability-vision",
- "sourceId": "KXRMGY",
- "title": "The verifiability vision",
- "description": "Imagine all data was guaranteed to be correct. We could build a trustworthy digital world based only on correct data. In this presentation, we will sketch layers and techniques that can realize this dream, in particular proof carrying data and succinct proofs. We will also discuss the connection to the proof singularity vision for Ethereum as well as highlight caveats that apply; humanity is still in the early stages of the journey and there are obstacles and constraints to tackle",
- "track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Verifiability",
- "proof carrying data",
- "succinct proofs"
- ],
- "tags": [
- "Scalability",
- "Vision",
- "ZKP",
- "proof",
- "succinct",
- "Scalability",
- "Vision",
- "ZKP"
- ],
- "language": "en",
- "speakers": [
- "jens-groth"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731578400000,
- "slot_end": 1731580200000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1D13mwNG569Eo7vRzSRs1BRHF7sCXAys5mnZEJpklwtg"
- },
- "vector": [
0,
0,
0,
@@ -780606,7 +779033,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -781190,6 +779616,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -781261,7 +779688,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -781291,6 +779717,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -781308,6 +779735,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -781369,10 +779797,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -781380,6 +779810,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -781396,13 +779827,16 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -781423,7 +779857,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -781477,6 +779910,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -781488,7 +779922,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -781572,7 +780005,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -781582,7 +780014,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -781693,6 +780124,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -781787,6 +780219,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -781830,12 +780264,14 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -781843,10 +780279,53 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "things-you-didnt-know-about-contract-deployment",
+ "sourceId": "GJM9UC",
+ "title": "Things you didn't know about contract deployment",
+ "description": "In this session we will explore some of the lesser-known facts around contract deployment. To make the presentation accessible to all technical levels, the talk will start by recapping the three ways to start contract deployment (deployment tx, CREATE, CREATE2). Following this, we will delve deeper into the topic and highlight some interesting facts around contract deployment, including what happens when an address already has code, ETH, or state entries at deployment.",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Developer",
+ "featured": false,
+ "doNotRecord": false,
+ "tags": [
+ "deployment"
+ ],
+ "keywords": [
+ "Deployment"
+ ],
+ "duration": 455,
+ "language": "en",
+ "sources_swarmHash": "e5fd22d186e8fffb80536b2b8384bfe34be27dc9ada6f8ec30c26118b31bbf63",
+ "sources_youtubeId": "BGT-VwLIbs0",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343af49dbb7a90e19dcf1a.vtt",
+ "transcript_text": " Hi everyone, good morning. My name is Teresa. I am a smart contract auditor at Chain Security and today I'll talk about things you didn't know about contract deployment. So I suppose many of you didn't know about contract deployment. So I suppose many of you have deployed a smart contract at some point. And this session aims to take a behind-the-scenes look at what happens at this process. So as a short recap, these are the three ways to deploy, to initiate smart contract deployment on Ethereum. So either via the creation transaction or the create or create two opcodes. All of these will trigger the EVM to execute the init code. So it will trigger construction execution. Now the question becomes, what if we want to deploy a contract at an address of an already existing account? Can we do that? And for that we must understand what it means for a contract for an account to exist. So let's recap that every account holds a state. We have a state that contains four fields, the nonce, the balance, the storage root, and the code hash. And for account existence, let's go all the way back to EIP-161 that specifies prior to the execution of the init code, the nonce is incremented by one. So this means for an address with a non-zero nonce, we can say an account exists at that address. But what does this mean? What are the implications on contract deployment? Can we deploy at an address with non-zero nonce or non-zero code hash? Well, we can't. There's EIP-64 that will revert if you try to initiate creation at an address with non-zero nonce and non-zero code hash. What about the storage? Do we need to care about the storage route? Interestingly, yes. There's also a check on that, And this has more of a historic flavor. There are still a few contracts on mainnet that have zero nonce, zero code hash, but non-zero storage. And these are from before EIP-161 that I just mentioned on the previous slides. All right, and what about the balance? Can we create at an address with non-zero balance? Yes, yes, we can. And then that number of way is just owned by the address. All right. Now, during contract construction, there's quite a specific behavior of the EVM. So usually, when you measure the code size of a contract from within a contract and Externally, it should give you the same size the same byte length Interestingly during deployment during contract construction. This does not hold so measuring the code size from within and From externally will give you different Values and this is an important detail to know and from externally, will give you different values. And this is an important detail to know. And one important aspect I would also want to shed a little light on is the values XcodeHash can take. And this is specifically important. If you do EOA checks using XcodeHash, you must know what states you can be in and what values Xcode hash can take. So for an empty account, so to recap, Xcode hash returns the code hash of the address you query. So for an empty account, that will be the value on the top right, the zero byte string. Now, if we deploy successfully to an empty address, this will just take any value the hash of the code deployed. Alright, now how can we get from the zero address from an empty account to the hash of the empty string? This is if you just send if to a random address where no contract lives. Xcode hash will return the hash of the empty string. And also during contract construction, this will be returned. Then from this value, you can, of course, then create on this contract. Because the nonce is still at this account, at this address, sorry, because the nonce is still set to zero. So you can create on that. Now, I want to finish off by asking if this is the complete picture. And in the interest of time, I'm taking this away for you. Well, no. You can still, still after Cancun, this still holds. So you must not rely, when you do an EOA check, that once you get the result of a random byte string that this will hold. Because within the same transaction, contract state can still be deleted. So don't let yourself be deceived by the return value of Xcode hash. So in summary, we've seen that for account existence, the launch is incremented. And this is done before constructor execution. We learned that you cannot create on existing accounts or on UAs. And there exists some legacy contracts with nonce zero storage, but zero nonce and zero code. And for the Xcode hash transitions, I really encourage you to try it out yourself. We set up this Remix workspace where you can measure the output of the opcodes and play around with that to really understand the transitions. Thank you very much for your attention, and if you want to reach out to us, I'm happy to chat after this talk, and you can also do so via the platforms. Thank you. Thank you, Tersa. Question time. The one I love the most. Who is going first? Question four. Oh, okay. I'll try. Yeah, so how would this EUA checks transform after the EIP 7702, where they implement the auth op code and then EUAs can also have EXT code? I'm not sure. Could you specify which EIP? The 7702, the auth op code EIP, where we can delegate EOS to contracts. I see. I'm not entirely sure about that, but what is important for now, after the Cancun upgrade, is that within the same transaction, you can have a creation, and you can have any function execution, and then still the self-destruct. And that is, I think, for right now, what is often left out of sight is that, yeah, it's still the same transaction and the self-destruct can still occur. Last question? One more question? No more question? Oh, okay. Teresa, thank you.",
+ "eventId": "devcon-7",
+ "slot_start": 1731470400000,
+ "slot_end": 1731471000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1j7qMdITP1J2AjDNnsbYHtP1ZqxF408IJ_kLSInVI0qU",
+ "resources_slides": null,
+ "speakers": [
+ "theresa-wakonig"
+ ]
+ },
+ "vector": [
0,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -781865,7 +780344,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -781909,12 +780387,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -781926,49 +780402,10 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "the-verkle-advantage",
- "sourceId": "YLBEZN",
- "title": "The verkle advantage",
- "description": "This talk provides a comprehensive overview of the achievements by the stateless development effort, over the past year. It will explore some of the discoveries we made while implementing verkle trees, that improve the user and developer experience of Ethereum.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "stateless"
- ],
- "tags": [
- "Core Protocol",
- "Protocol Design",
- "Verkle trees",
- "stateless",
- "Core Protocol",
- "Protocol Design",
- "Verkle trees"
- ],
- "language": "en",
- "speakers": [
- "guillaume-ballet"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731488400000,
- "slot_end": 1731490200000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1zs9ePGkdyS7IfCoOeK_dArKiELQYjDXk5L-A70d7Gf4"
- },
- "vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -782548,6 +780985,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -782630,7 +781068,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -782735,7 +781172,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -782762,7 +781198,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -782909,7 +781344,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -782985,6 +781419,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -783195,11 +781630,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -783210,12 +781647,51 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "this-cursed-machine-onchain-game-post-mortem",
+ "sourceId": "UBFQ9V",
+ "title": "THIS CURSED MACHINE: Onchain Game Post-Mortem",
+ "description": "“Live in the pod, fulfil orders, get bugs.”\r\n\r\nTHIS CURSED MACHINE is a fully onchain sci-fi body horror fulfilment center simulator by Moving Castles, a game studio for the tactical research and development of autonomous worlds.\r\n\r\nWe will speak about learnings of launching an autonomous world onchain (Redstone) and how we embraced the emergent chaos by making the bot attacks, exploits and player corporations part of the narrative of the world itself.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Product",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "Worldbuilding"
+ ],
+ "tags": [
+ "Best Practices",
+ "Gaming",
+ "Autonomous World",
+ "worldbuilding",
+ "Autonomous World",
+ "Best Practices",
+ "Gaming"
+ ],
+ "language": "en",
+ "speakers": [
+ "arb"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731486600000,
+ "slot_end": 1731488400000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1cXPZD6cWdMNr2QSeVuUQ8-WSQ_YhrCRA6-l3ClLl2n0"
+ },
+ "vector": [
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -783234,7 +781710,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -783277,11 +781752,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -783294,46 +781767,6 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "the-wallet-and-ux-stack-to-build-web3-applications-for-the-masses",
- "sourceId": "LCNEGW",
- "title": "The Wallet and UX Stack to Build Web3 Applications for the Masses",
- "description": "In this talk I will give an overview of how wallet infrastructure and the relationship between wallets and dapps have evolved over the past 5 years. And give a layer-by-layer breakdown of the modern wallet stack from signers to smart account modules, how each component contributes to a UX unlock on Ethereum/L2s, and how application developers can use them today. We will also touch on pertinent ongoing EIPs such as 7702 (deploy code for EOAs), and 7715 (permissions).",
- "track": "Usability",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Product",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Wallets",
- "Signers",
- "Permissions"
- ],
- "tags": [
- "Developer Infrastructure",
- "User Experience",
- "Account Abstraction",
- "permissions",
- "Account Abstraction",
- "Developer Infrastructure",
- "User Experience"
- ],
- "language": "en",
- "speakers": [
- "nichanan-kesonpat"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731470400000,
- "slot_end": 1731472200000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1EwxJbkAW9PZZpjRozkPVAnLaQpoQZm7uf1kolnUFM_0"
- },
- "vector": [
0,
0,
0,
@@ -783342,7 +781775,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -783919,6 +782351,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -784001,7 +782434,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -784033,6 +782465,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -784102,7 +782535,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -784112,6 +782544,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -784137,10 +782571,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -784522,6 +782954,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -784564,11 +782997,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -784577,12 +783012,43 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "this-year-in-ethereum",
+ "sourceId": "MFBX7X",
+ "title": "This year in Ethereum",
+ "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.",
+ "track": "Real World Ethereum",
+ "type": "Talk",
+ "expertise": "",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [],
+ "tags": [],
+ "language": "en",
+ "speakers": [
+ "josh-stark"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731381300000,
+ "slot_end": 1731382800000,
+ "slot_roomId": "main-stage",
+ "sources_youtubeId": "YyK8i2-0aPk",
+ "sources_swarmHash": "42b2f958a6ad4ec1fc91b8dd669da09457cace9ae38b40d9772bcc6a5851ab4a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1jnpwsT-B0lnVYIbUt5XuDZoqqTEjj666EzfAz3-aSZY"
+ },
+ "vector": [
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -784605,7 +783071,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -784647,7 +783112,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -784655,7 +783119,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -784664,68 +783127,12 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "the-wellbeing-protocol-scaling-localism",
- "sourceId": "HC3QGN",
- "title": "The Wellbeing Protocol - Scaling Localism",
- "description": "Imagine a world where:\r\n - hyper-local marginalised communities could create impact DAOs as easily as creating FB groups\r\n - we could create a UI that abstracted the complexity of quadratic / conviction / delegated voting to create a continuous resource allocation alternative to governance\r\n - funders could stream money into millions of these treasuries\r\n\r\nFind out how this New Zealand government funded project, now running trials in three countries, is creating a network of grassroots changemakers.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Community",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "conviction",
- "zealand"
- ],
- "tags": [
- "DAO",
- "Governance",
- "Quadratic Voting",
- "Collective Intelligence",
- "Conviction",
- "Ethereum for Good",
- "Public good",
- "Climate",
- "ReFi",
- "Regenerative Applications",
- "User Experience",
- "zealand",
- "Climate",
- "Collective Intelligence",
- "Conviction",
- "DAO",
- "Ethereum for Good",
- "Governance",
- "Public good",
- "Quadratic Voting",
- "ReFi",
- "Regenerative Applications",
- "User Experience"
- ],
- "language": "en",
- "speakers": [
- "mark-pascall"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731481200000,
- "slot_end": 1731481800000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1RsF9WALoUv0Wv3Pc036sfCbuKskiOHZzZRM1r385Iew"
- },
- "vector": [
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -785302,6 +783709,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -785387,7 +783795,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -785487,7 +783894,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -785505,7 +783911,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -785567,12 +783972,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -785580,7 +783983,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -785597,16 +783999,13 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -785680,7 +784079,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -785895,7 +784293,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -785956,8 +784353,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -785970,8 +784369,53 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "time-is-all-you-need-optimizing-dutch-auctions-on-arbitrum",
+ "sourceId": "QNSX9R",
+ "title": "Time is all you need: optimizing Dutch auctions on Arbitrum",
+ "description": "Dutch auctions are a common approach in MEV-mitigating mechanism designs. However, little work has been done in exploring optimal auction execution times. Using simulations, we demonstrate how optimizing for a key metric — wait time — can achieve optimal execution without the complexity of existing systems.",
+ "track": "Cryptoeconomics",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Research",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "Dutch",
+ "auctions"
+ ],
+ "tags": [
+ "Decentralization Improvements",
+ "Layer 2s",
+ "Mechanism design",
+ "MEV",
+ "auction",
+ "dutch",
+ "Decentralization Improvements",
+ "Layer 2s",
+ "Mechanism design",
+ "MEV"
+ ],
+ "language": "en",
+ "speakers": [
+ "brad-bachu",
+ "cody-born",
+ "alan-wu"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731489000000,
+ "slot_end": 1731489600000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1DhrF39oif7Piw0FK877aPOnLTq12Z7iwOXeKa33SnVU"
+ },
+ "vector": [
0,
0,
+ 6,
0,
0,
0,
@@ -785991,8 +784435,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -786034,14 +784476,12 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -786049,52 +784489,10 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "things-you-didnt-know-about-contract-deployment",
- "sourceId": "GJM9UC",
- "title": "Things you didn't know about contract deployment",
- "description": "In this session we will explore some of the lesser-known facts around contract deployment. To make the presentation accessible to all technical levels, the talk will start by recapping the three ways to start contract deployment (deployment tx, CREATE, CREATE2). Following this, we will delve deeper into the topic and highlight some interesting facts around contract deployment, including what happens when an address already has code, ETH, or state entries at deployment.",
- "track": "Core Protocol",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Developer",
- "featured": false,
- "doNotRecord": false,
- "tags": [
- "deployment"
- ],
- "keywords": [
- "Deployment"
- ],
- "duration": 455,
- "language": "en",
- "sources_swarmHash": "e5fd22d186e8fffb80536b2b8384bfe34be27dc9ada6f8ec30c26118b31bbf63",
- "sources_youtubeId": "BGT-VwLIbs0",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343af49dbb7a90e19dcf1a.vtt",
- "transcript_text": " Hi everyone, good morning. My name is Teresa. I am a smart contract auditor at Chain Security and today I'll talk about things you didn't know about contract deployment. So I suppose many of you didn't know about contract deployment. So I suppose many of you have deployed a smart contract at some point. And this session aims to take a behind-the-scenes look at what happens at this process. So as a short recap, these are the three ways to deploy, to initiate smart contract deployment on Ethereum. So either via the creation transaction or the create or create two opcodes. All of these will trigger the EVM to execute the init code. So it will trigger construction execution. Now the question becomes, what if we want to deploy a contract at an address of an already existing account? Can we do that? And for that we must understand what it means for a contract for an account to exist. So let's recap that every account holds a state. We have a state that contains four fields, the nonce, the balance, the storage root, and the code hash. And for account existence, let's go all the way back to EIP-161 that specifies prior to the execution of the init code, the nonce is incremented by one. So this means for an address with a non-zero nonce, we can say an account exists at that address. But what does this mean? What are the implications on contract deployment? Can we deploy at an address with non-zero nonce or non-zero code hash? Well, we can't. There's EIP-64 that will revert if you try to initiate creation at an address with non-zero nonce and non-zero code hash. What about the storage? Do we need to care about the storage route? Interestingly, yes. There's also a check on that, And this has more of a historic flavor. There are still a few contracts on mainnet that have zero nonce, zero code hash, but non-zero storage. And these are from before EIP-161 that I just mentioned on the previous slides. All right, and what about the balance? Can we create at an address with non-zero balance? Yes, yes, we can. And then that number of way is just owned by the address. All right. Now, during contract construction, there's quite a specific behavior of the EVM. So usually, when you measure the code size of a contract from within a contract and Externally, it should give you the same size the same byte length Interestingly during deployment during contract construction. This does not hold so measuring the code size from within and From externally will give you different Values and this is an important detail to know and from externally, will give you different values. And this is an important detail to know. And one important aspect I would also want to shed a little light on is the values XcodeHash can take. And this is specifically important. If you do EOA checks using XcodeHash, you must know what states you can be in and what values Xcode hash can take. So for an empty account, so to recap, Xcode hash returns the code hash of the address you query. So for an empty account, that will be the value on the top right, the zero byte string. Now, if we deploy successfully to an empty address, this will just take any value the hash of the code deployed. Alright, now how can we get from the zero address from an empty account to the hash of the empty string? This is if you just send if to a random address where no contract lives. Xcode hash will return the hash of the empty string. And also during contract construction, this will be returned. Then from this value, you can, of course, then create on this contract. Because the nonce is still at this account, at this address, sorry, because the nonce is still set to zero. So you can create on that. Now, I want to finish off by asking if this is the complete picture. And in the interest of time, I'm taking this away for you. Well, no. You can still, still after Cancun, this still holds. So you must not rely, when you do an EOA check, that once you get the result of a random byte string that this will hold. Because within the same transaction, contract state can still be deleted. So don't let yourself be deceived by the return value of Xcode hash. So in summary, we've seen that for account existence, the launch is incremented. And this is done before constructor execution. We learned that you cannot create on existing accounts or on UAs. And there exists some legacy contracts with nonce zero storage, but zero nonce and zero code. And for the Xcode hash transitions, I really encourage you to try it out yourself. We set up this Remix workspace where you can measure the output of the opcodes and play around with that to really understand the transitions. Thank you very much for your attention, and if you want to reach out to us, I'm happy to chat after this talk, and you can also do so via the platforms. Thank you. Thank you, Tersa. Question time. The one I love the most. Who is going first? Question four. Oh, okay. I'll try. Yeah, so how would this EUA checks transform after the EIP 7702, where they implement the auth op code and then EUAs can also have EXT code? I'm not sure. Could you specify which EIP? The 7702, the auth op code EIP, where we can delegate EOS to contracts. I see. I'm not entirely sure about that, but what is important for now, after the Cancun upgrade, is that within the same transaction, you can have a creation, and you can have any function execution, and then still the self-destruct. And that is, I think, for right now, what is often left out of sight is that, yeah, it's still the same transaction and the self-destruct can still occur. Last question? One more question? No more question? Oh, okay. Teresa, thank you.",
- "eventId": "devcon-7",
- "slot_start": 1731470400000,
- "slot_end": 1731471000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1j7qMdITP1J2AjDNnsbYHtP1ZqxF408IJ_kLSInVI0qU",
- "resources_slides": null,
- "speakers": [
- "theresa-wakonig"
- ]
- },
- "vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -786683,6 +785081,9 @@
0,
0,
0,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -786759,14 +785160,16 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -786825,6 +785228,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -787085,6 +785489,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -787193,7 +785598,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -787279,6 +785683,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -787318,10 +785723,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -787333,6 +785740,46 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "tlsnotary-applying-mpc-and-interactive-zk-to-prove-web2-data",
+ "sourceId": "RTVKJC",
+ "title": "TLSNotary: Applying MPC and interactive ZK to prove web2 data",
+ "description": "Diving into TLSNotary, a protocol which leverages multi-party computation and interactive ZK to prove the authenticity and provenance of any data on the web to another party.\r\n\r\nSummary:\r\n1. What it is and what it can do\r\n2. High-level overview of how it works\r\n3. Details on the underlying MPC and ZK protocols that we use\r\n4. How to use it",
+ "track": "Applied Cryptography",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "User Sovereignty",
+ "Infrastructure",
+ "Oracle"
+ ],
+ "tags": [
+ "Identity",
+ "ZKP",
+ "MPC",
+ "oracle",
+ "Identity",
+ "MPC",
+ "ZKP"
+ ],
+ "language": "en",
+ "speakers": [
+ "sinu"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731576600000,
+ "slot_end": 1731577200000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/1XH5xVNY-eLNdwvYduookcntMG3Z4qjU319sqNmXxUXo"
+ },
+ "vector": [
0,
0,
0,
@@ -787343,6 +785790,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -787403,13 +785851,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -787420,51 +785866,12 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "this-cursed-machine-onchain-game-post-mortem",
- "sourceId": "UBFQ9V",
- "title": "THIS CURSED MACHINE: Onchain Game Post-Mortem",
- "description": "“Live in the pod, fulfil orders, get bugs.”\r\n\r\nTHIS CURSED MACHINE is a fully onchain sci-fi body horror fulfilment center simulator by Moving Castles, a game studio for the tactical research and development of autonomous worlds.\r\n\r\nWe will speak about learnings of launching an autonomous world onchain (Redstone) and how we embraced the emergent chaos by making the bot attacks, exploits and player corporations part of the narrative of the world itself.",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Product",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Worldbuilding"
- ],
- "tags": [
- "Best Practices",
- "Gaming",
- "Autonomous World",
- "worldbuilding",
- "Autonomous World",
- "Best Practices",
- "Gaming"
- ],
- "language": "en",
- "speakers": [
- "arb"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731486600000,
- "slot_end": 1731488400000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1cXPZD6cWdMNr2QSeVuUQ8-WSQ_YhrCRA6-l3ClLl2n0"
- },
- "vector": [
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -788044,6 +786451,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -788128,7 +786536,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -788171,6 +786578,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -788196,6 +786604,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -788209,6 +786618,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -788241,7 +786651,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -788320,8 +786729,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -788557,6 +786964,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -788682,9 +787090,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -788697,10 +787107,48 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "today-verkle-tomorrow-zk-everything-stateless-everything-lightclient",
+ "sourceId": "Z8EEGW",
+ "title": "Today Verkle + Tomorrow ZK = Everything Stateless, Everything Lightclient",
+ "description": "Statelessness could be one of the biggest unlocks in the Ethereum ecosystem, allowing the protocol to scale massively without giving away control and access to big entities, all while providing some real 'teeth' to the light client ecosystem.\r\n\r\nIn this talk, we’ll see how stateless clients enable immediate scalability and decentralization benefits, and how combining statelessness with ZKing the state transitions unlocks Ethereum’s long-term vision.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "statelessness"
+ ],
+ "tags": [
+ "Light Clients",
+ "Zero-Knowledge",
+ "statelessness",
+ "Light Clients",
+ "Zero-Knowledge"
+ ],
+ "language": "en",
+ "speakers": [
+ "jason-chaskin",
+ "gajinder-singh"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731490200000,
+ "slot_end": 1731492000000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1vOoQZu3TYR_edc7RAy-eEqHYRvkAPSwPJBk3veKBxRM"
+ },
+ "vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -788732,7 +787180,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -788773,13 +787220,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -788788,43 +787233,12 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "this-year-in-ethereum",
- "sourceId": "MFBX7X",
- "title": "This year in Ethereum",
- "description": "Don’t miss the Devcon Opening Ceremony, where we’ll set the stage for an incredible event ahead, with talks from Vitalik Buterin (Founder of Ethereum), Aya Miyaguchi (Executive Director of the Ethereum Foundation), Josh Stark (Ethereum Foundation Leadership), Skylar Weaver (Devcon Team Lead), and more surprise guests.",
- "track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "keywords": [],
- "tags": [],
- "language": "en",
- "speakers": [
- "josh-stark"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731381300000,
- "slot_end": 1731382800000,
- "slot_roomId": "main-stage",
- "sources_youtubeId": "YyK8i2-0aPk",
- "sources_swarmHash": "42b2f958a6ad4ec1fc91b8dd669da09457cace9ae38b40d9772bcc6a5851ab4a",
- "resources_presentation": "https://docs.google.com/presentation/d/1jnpwsT-B0lnVYIbUt5XuDZoqqTEjj666EzfAz3-aSZY"
- },
- "vector": [
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -789402,6 +787816,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -789497,6 +787913,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -789998,6 +788415,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -790036,9 +788454,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -790051,6 +788471,32 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "tomo-dj-set",
+ "sourceId": "3FTAT3",
+ "title": "Tomo DJ Set",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [],
+ "tags": [],
+ "language": "en",
+ "speakers": [],
+ "eventId": "devcon-7",
+ "slot_start": 1731583800000,
+ "slot_end": 1731588600000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1537a7C9-ILckCdyKNCQyYB-I6Kwu_xrA6i0Sk2-j9eU"
+ },
+ "vector": [
0,
0,
0,
@@ -790060,6 +788506,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -790132,10 +788579,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -790148,53 +788593,8 @@
0,
0,
0,
- 0
- ]
- },
- {
- "session": {
- "id": "time-is-all-you-need-optimizing-dutch-auctions-on-arbitrum",
- "sourceId": "QNSX9R",
- "title": "Time is all you need: optimizing Dutch auctions on Arbitrum",
- "description": "Dutch auctions are a common approach in MEV-mitigating mechanism designs. However, little work has been done in exploring optimal auction execution times. Using simulations, we demonstrate how optimizing for a key metric — wait time — can achieve optimal execution without the complexity of existing systems.",
- "track": "Cryptoeconomics",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Research",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Dutch",
- "auctions"
- ],
- "tags": [
- "Decentralization Improvements",
- "Layer 2s",
- "Mechanism design",
- "MEV",
- "auction",
- "dutch",
- "Decentralization Improvements",
- "Layer 2s",
- "Mechanism design",
- "MEV"
- ],
- "language": "en",
- "speakers": [
- "brad-bachu",
- "cody-born",
- "alan-wu"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731489000000,
- "slot_end": 1731489600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1DhrF39oif7Piw0FK877aPOnLTq12Z7iwOXeKa33SnVU"
- },
- "vector": [
0,
0,
- 6,
0,
0,
0,
@@ -790864,9 +789264,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
0,
0,
0,
@@ -790946,12 +789343,9 @@
0,
0,
0,
- 6,
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -791010,7 +789404,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -791272,58 +789665,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -791470,50 +789811,11 @@
2,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
2,
0,
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -791527,41 +789829,43 @@
},
{
"session": {
- "id": "tlsnotary-applying-mpc-and-interactive-zk-to-prove-web2-data",
- "sourceId": "RTVKJC",
- "title": "TLSNotary: Applying MPC and interactive ZK to prove web2 data",
- "description": "Diving into TLSNotary, a protocol which leverages multi-party computation and interactive ZK to prove the authenticity and provenance of any data on the web to another party.\r\n\r\nSummary:\r\n1. What it is and what it can do\r\n2. High-level overview of how it works\r\n3. Details on the underlying MPC and ZK protocols that we use\r\n4. How to use it",
- "track": "Applied Cryptography",
- "type": "Lightning Talk",
+ "id": "top-hacks-since-devcon-vi-what-did-we-learn",
+ "sourceId": "FCWCBG",
+ "title": "Top Hacks since Devcon VI: what did we learn?",
+ "description": "Discover the most daring blockchain hacks of '22-'24 and how to defend against them. Join Mudit Gupta, CISO of Polygon, and Matthias Egli from ChainSecurity for an analysis of tactics and vulnerabilities, and gain valuable insights to stay ahead of the game. And stay tuned for a prominent anon surprise guest!",
+ "track": "Security",
+ "type": "Workshop",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "User Sovereignty",
- "Infrastructure",
- "Oracle"
+ "Learnings",
+ "War Rooms"
],
"tags": [
- "Identity",
- "ZKP",
- "MPC",
- "oracle",
- "Identity",
- "MPC",
- "ZKP"
+ "Security",
+ "Hacks",
+ "Use Cases",
+ "war",
+ "room",
+ "Hacks",
+ "Security",
+ "Use Cases"
],
"language": "en",
"speakers": [
- "sinu"
+ "matthias-egli",
+ "mudit-gupta"
],
"eventId": "devcon-7",
- "slot_start": 1731576600000,
- "slot_end": 1731577200000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/1XH5xVNY-eLNdwvYduookcntMG3Z4qjU319sqNmXxUXo"
+ "slot_start": 1731483000000,
+ "slot_end": 1731488400000,
+ "slot_roomId": "classroom-b",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Ic4xQqu3tPIGtBkRi-td-CDrhLlNwW9GBWn1_dYegTE"
},
"vector": [
+ 6,
0,
0,
0,
@@ -791572,7 +789876,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -791811,6 +790114,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -792005,6 +790309,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -792237,7 +790542,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -792310,6 +790614,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -792363,7 +790668,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -792403,12 +790707,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -792566,6 +790864,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -792752,7 +791051,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -792839,6 +791137,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -792897,36 +791197,41 @@
},
{
"session": {
- "id": "today-verkle-tomorrow-zk-everything-stateless-everything-lightclient",
- "sourceId": "Z8EEGW",
- "title": "Today Verkle + Tomorrow ZK = Everything Stateless, Everything Lightclient",
- "description": "Statelessness could be one of the biggest unlocks in the Ethereum ecosystem, allowing the protocol to scale massively without giving away control and access to big entities, all while providing some real 'teeth' to the light client ecosystem.\r\n\r\nIn this talk, we’ll see how stateless clients enable immediate scalability and decentralization benefits, and how combining statelessness with ZKing the state transitions unlocks Ethereum’s long-term vision.",
+ "id": "top-opcode-offenders-in-the-zkevm",
+ "sourceId": "DJL7RP",
+ "title": "Top opcode offenders in the zkEVM",
+ "description": "One of the challenges for any L2 is to reflect accurately the cost for each opcode in zk-resources.\r\nEthereum L1 reflects the resource cost in term of GAS but lately it has been proposed chnages in opcode GAS cost to fit the zk-world to make Ethreum L1 more aligned to L2 or even with enshrined zk-rollups.\r\nIn this talk, I will explain the worst performance opcodes when comparing its GAS cost Vs zk-resources cost in Polygon zkEVM in typical transactions (erc20 trannsfers, swaps, ...)",
"track": "Core Protocol",
"type": "Talk",
- "expertise": "Intermediate",
+ "expertise": "Expert",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "statelessness"
+ "zk-resources",
+ "GAS costs",
+ "top offenders"
],
"tags": [
- "Light Clients",
- "Zero-Knowledge",
- "statelessness",
- "Light Clients",
- "Zero-Knowledge"
+ "Core Protocol",
+ "Layer 2s",
+ "Zk Rollups",
+ "top",
+ "offenders",
+ "Core Protocol",
+ "Layer 2s",
+ "Zk Rollups"
],
"language": "en",
"speakers": [
- "jason-chaskin",
- "gajinder-singh"
+ "carlos-matallana",
+ "jesus"
],
"eventId": "devcon-7",
"slot_start": 1731490200000,
"slot_end": 1731492000000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1vOoQZu3TYR_edc7RAy-eEqHYRvkAPSwPJBk3veKBxRM"
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1NcWox_AiyJE1F6zW2KLfOoCFpaY0DVyowm34wlSdbao"
},
"vector": [
0,
@@ -793432,6 +791737,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -793602,10 +791908,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 6,
6,
0,
0,
@@ -793693,7 +791995,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -793748,8 +792049,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -794206,6 +792509,7 @@
0,
0,
2,
+ 2,
0,
0,
0,
@@ -794242,11 +792546,9 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
2,
+ 2,
0,
0,
0,
@@ -794264,42 +792566,41 @@
},
{
"session": {
- "id": "tomo-dj-set",
- "sourceId": "3FTAT3",
- "title": "Tomo DJ Set",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
+ "id": "tracing-integration-in-lighthouse",
+ "sourceId": "RVZX3C",
+ "title": "Tracing Integration in Lighthouse",
+ "description": "During Ethereum Protocol Fellowship, I've worked on integrating `Tracing`(an async-friendly logging framework) into Lighthouse(CL client) .\r\nThis presentation will provide a brief overview of the work that I’ve done.",
+ "track": "[CLS] EPF Day",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
+ "tags": [
+ "Core Protocol",
+ "Frameworks"
+ ],
"keywords": [],
- "tags": [],
+ "duration": 841,
"language": "en",
- "speakers": [],
+ "sources_swarmHash": "175d7bc039ec1952a66d831fd8c59ca61cd356e1f223f38794226fa65f26d38e",
+ "sources_youtubeId": "oHndT2i3rnc",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343e3a9dbb7a90e1dcb5b6.vtt",
+ "transcript_text": " Lighthouse, another fellow contributing to Lighthouse consensus client, this time integrating the logging framework tracing into Lighthouse. So thanks for being here. Yeah, go ahead. Hello, everyone. So, first of all, let me say this, that my project isn't that cool. It's kind of like tedious and large-sized chore. You guys will get to witness many cool projects, so I'll just keep my",
"eventId": "devcon-7",
- "slot_start": 1731583800000,
- "slot_end": 1731588600000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1537a7C9-ILckCdyKNCQyYB-I6Kwu_xrA6i0Sk2-j9eU"
+ "slot_start": 1731474900000,
+ "slot_end": 1731475800000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1RQXvuQDzdyRtC3YArjUnvZw9pKG8y3WwlKPipk1FNJE",
+ "resources_slides": null,
+ "speakers": [
+ "sayan"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -794315,6 +792616,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -794974,6 +793276,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -795066,6 +793369,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -795151,6 +793455,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -795599,11 +793911,12 @@
0,
0,
0,
- 2,
0,
0,
2,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -795620,40 +793933,46 @@
},
{
"session": {
- "id": "top-hacks-since-devcon-vi-what-did-we-learn",
- "sourceId": "FCWCBG",
- "title": "Top Hacks since Devcon VI: what did we learn?",
- "description": "Discover the most daring blockchain hacks of '22-'24 and how to defend against them. Join Mudit Gupta, CISO of Polygon, and Matthias Egli from ChainSecurity for an analysis of tactics and vulnerabilities, and gain valuable insights to stay ahead of the game. And stay tuned for a prominent anon surprise guest!",
+ "id": "transaction-simulation-the-good-the-bad-and-the-ugly",
+ "sourceId": "TE9JUF",
+ "title": "Transaction simulation, the good, the bad & the ugly",
+ "description": "Transaction simulation allows users to preview the outcomes of signing a transaction, enabling them to make informed decisions rather than fully trusting the dApp. However, several caveats and risks are associated with relying on simulated transaction outcomes. State changes, differing contract behavior between simulation and on-chain execution, and randomness can all affect the outcome. In this talk, I'll share my experiences and learnings from simulating user transactions over the past 2 years",
"track": "Security",
- "type": "Workshop",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Learnings",
- "War Rooms"
- ],
"tags": [
"Security",
- "Hacks",
- "Use Cases",
- "war",
- "room",
- "Hacks",
+ "User Experience",
+ "safety",
"Security",
- "Use Cases"
+ "User Experience"
],
- "language": "en",
- "speakers": [
- "matthias-egli",
- "mudit-gupta"
+ "keywords": [
+ "simulation",
+ "wallet",
+ "safety"
],
+ "duration": 458,
+ "language": "en",
+ "sources_swarmHash": "1367b463e69cb498817ffc03a9949daeade7c14957d466768d66c65a2b542e0f",
+ "sources_youtubeId": "12uW2nhIxN4",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333e6c3a168eb53500581d.vtt",
+ "transcript_text": " Hello everyone. My name is Shi, and I'm a security engineer at Fasen. And for the past year, we have been digging into the Amoeba world, so we have some insights to share to bring some new methodologies into this world. And the topic is how to front-run a transaction in the future. So in 2023, we have seen a lot of front-runners have rescued millions of dollars in the hack incidents. For example, they rescued 5.4 million, and also BlockSec. And also in the Khyber-Swab incident, they rescued 5.7 million and returned those funds to the protocols. These are like white hat hackers. But we are seeing a declining trend for this in 2024. And there are some reasons for that. So before that, let me go over about the background of MEV and front-running. So this is how a transaction's lifecycle. So on the top, you can see when the user wants to send the transaction, he wants to send it to the builder first, then the validator. Then the validator will propose a block and commit it to the chain. But if there is a frontrunner, when the user sends a transaction to the builder, the frontrunner will see this transaction. And when he detects this transaction is profitable, he'll replace the beneficiary to himself, and then add a little bit more gas onto that. So the builder will place his transaction in front of the normal transaction. So the user's transaction his transaction in front of the normal transaction. So the user's transaction will be reverted. So the frontrunner will gain profit from this. So then the role of private mempool came. They say we will keep transaction private. And this is beneficiary for most parties. First, arbitrage are fair. Like, at MVVBoss, they want to balance the pools. They find a better swap path win. And also, users, they don't need to suffer from sandwiches. And also, the side effect of this is that hackers transactions, they are protected by the private pool as well. For example, in the previous examples, those frontrunners are not able to frontrun with a private transaction. And is frontrunning dead? And we found the answer to this question is no, not on the block level. Let me explain that. So we have seen a lot of patterns like this. It's called a two-phase style attack. So first, if a hacker wants to hack something, he will first deploy a assistant contract and do some preparation. And finally, he'll send another transaction to trigger the vulnerable function of the victim. So to exploit it, all a map bot or a frontrunner needs to do is to extract all the functions of a contract by using the function signatures and call every function. And if it happens to be the trigger function, a contract by using the function signatures and call every function. And if it happens to be the trigger function, a frontrunner will be able to frontrun this transaction that has never been sent to the builder before. And so it becomes a cat and mouse game between the MEV bots and hackers. And hackers, they thought of some better strategies to protect their contracts. For example, here we have address verification. Basically, it's easy to bypass. All a bot needs to do is to add some hints. And also, if it has an authentication, like here you have a hash of some address. If it's compared to a fixed hash. But all a bot needs to do is to change that equal sign to a not equal sign. And also, then hackers thought of some more sophisticated methods. For example, they hide the parameter to the vulnerable function directly in the parameter in the function. And we found that the goal is really to find the input to trigger a profitable path in the contract because it's already in this contract. And fuzzing is a good tool to do that. So what is fuzzing? It's basically generate a random input. This random is not really random. And then it executes the program, observe and analyze the execution, collect interesting information. And if it's a profitable path, we will exit. Otherwise, we repeat using the collected information. And there are different purposes for fuzzing. In Web 2, you might be corrupting some memory. In Web 3, all this space, it might be breaking some invariants. And here, we are really to find a profitable path. So the effects really depends on the input generation. Here are some heuristic functions or generation methods we want to offer you. And the important thing is about the heuristic functions. These are the that makes the fuzzing different. And there are some pros and cons to fuzzing. For example, it's fast, accurate, and easy to build a prototype. And also, for the cons, it can be time consuming, especially in some chains that have a very low block time interval. And what we want to promote is that I think we should bring more Web 2.0 methodologies into Web 3.0. For example, we haven't seen static analysis, something like that. We're bringing fuzzing, also adding some tint analysis and symbolic execution into our engine. And yeah, we're hoping to see more of this. And that's the end of my talk. I'm ready to take any questions. Thank you so much, Qi. Any questions? The last chance to ask questions before the end of today. Anyone wants to give a go? No questions? Okay. Thank you, Chi. And that wraps up the day of Lightning Talks. What an incredible series we had today. And thanks for attending and all our speakers. And tomorrow we'll continue. So hopefully see you tomorrow. Thank you. you",
"eventId": "devcon-7",
- "slot_start": 1731483000000,
- "slot_end": 1731488400000,
- "slot_roomId": "classroom-b",
- "resources_presentation": "https://docs.google.com/presentation/d/1Ic4xQqu3tPIGtBkRi-td-CDrhLlNwW9GBWn1_dYegTE"
+ "slot_start": 1731409800000,
+ "slot_end": 1731410400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Bl4qs4Zj65LUtt4i8uht8GdKLHGxRkYht0gt_Qcd_n4",
+ "resources_slides": null,
+ "speakers": [
+ "kim-persson"
+ ]
},
"vector": [
6,
@@ -795905,7 +794224,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -796101,7 +794419,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -796334,6 +794651,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -796406,9 +794724,9 @@
0,
0,
0,
+ 6,
0,
0,
- 6,
0,
0,
0,
@@ -796422,6 +794740,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -796487,7 +794806,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -796659,7 +794977,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -796707,6 +795024,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -796933,8 +795251,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -796991,48 +795307,41 @@
},
{
"session": {
- "id": "top-opcode-offenders-in-the-zkevm",
- "sourceId": "DJL7RP",
- "title": "Top opcode offenders in the zkEVM",
- "description": "One of the challenges for any L2 is to reflect accurately the cost for each opcode in zk-resources.\r\nEthereum L1 reflects the resource cost in term of GAS but lately it has been proposed chnages in opcode GAS cost to fit the zk-world to make Ethreum L1 more aligned to L2 or even with enshrined zk-rollups.\r\nIn this talk, I will explain the worst performance opcodes when comparing its GAS cost Vs zk-resources cost in Polygon zkEVM in typical transactions (erc20 trannsfers, swaps, ...)",
- "track": "Core Protocol",
+ "id": "transforming-systems-lessons-from-taiwans-movements",
+ "sourceId": "B9EDKY",
+ "title": "Transforming Systems: Lessons from Taiwan's Movements",
+ "description": "I will talk about the most recent struggles of open source communities in Taiwan, g0v specifically, how da0 has been trying to help in the past year or so, the conclusions we had and what is still missing. g0v has been running bi-monthly hackathons for 10 years now, which has been the key foundation for the community. April this year they stopped due to lack of funding support, we use this as a point of reference and how a web3 oriented subgroup like da0 could have done better, and the future.",
+ "track": "Coordination",
"type": "Talk",
- "expertise": "Expert",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "zk-resources",
- "GAS costs",
- "top offenders"
+ "Ecosystem",
+ "Funding",
+ "Mainstream"
],
"tags": [
- "Core Protocol",
- "Layer 2s",
- "Zk Rollups",
- "top",
- "offenders",
- "Core Protocol",
- "Layer 2s",
- "Zk Rollups"
+ "Civil Resistance",
+ "Coordination",
+ "Public good"
],
"language": "en",
"speakers": [
- "carlos-matallana",
- "jesus"
+ "noah-yeh"
],
"eventId": "devcon-7",
- "slot_start": 1731490200000,
- "slot_end": 1731492000000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1NcWox_AiyJE1F6zW2KLfOoCFpaY0DVyowm34wlSdbao"
+ "slot_start": 1731638700000,
+ "slot_end": 1731639900000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1mKMsPFBtVYtAcJOczCaTR2Ssw6fiQ86zw-Jz3zyGmFk"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -797040,6 +795349,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -797536,7 +795846,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -797799,8 +796108,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -797846,10 +796153,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -797891,6 +796196,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -797936,6 +796242,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -798009,6 +796316,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -798307,8 +796615,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -798345,13 +796651,14 @@
0,
0,
2,
- 2,
0,
0,
0,
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -798363,49 +796670,48 @@
},
{
"session": {
- "id": "tracing-integration-in-lighthouse",
- "sourceId": "RVZX3C",
- "title": "Tracing Integration in Lighthouse",
- "description": "During Ethereum Protocol Fellowship, I've worked on integrating `Tracing`(an async-friendly logging framework) into Lighthouse(CL client) .\r\nThis presentation will provide a brief overview of the work that I’ve done.",
- "track": "[CLS] EPF Day",
+ "id": "transitioning-from-an-l1-to-an-l2-a-case-study",
+ "sourceId": "KHVZ9M",
+ "title": "Transitioning from an L1 to an L2: A case study",
+ "description": "This talk will cover the learnings from cLabs' experience rebuilding Celo from the ground up as an L2. We hope that it can be a useful case study for other L1s to follow.",
+ "track": "Layer 2",
"type": "Lightning Talk",
- "expertise": "Beginner",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
+ "keywords": [
+ "Layer2",
+ "case study",
+ "technical learnings"
+ ],
"tags": [
- "Core Protocol",
- "Frameworks"
+ "Layer 1",
+ "Layer 2s",
+ "Rollups",
+ "Scalability",
+ "Optimistic rollups",
+ "Use Cases",
+ "learnings",
+ "technical",
+ "Layer 1",
+ "Layer 2s",
+ "Optimistic rollups",
+ "Rollups",
+ "Scalability",
+ "Use Cases"
],
- "keywords": [],
- "duration": 841,
"language": "en",
- "sources_swarmHash": "175d7bc039ec1952a66d831fd8c59ca61cd356e1f223f38794226fa65f26d38e",
- "sources_youtubeId": "oHndT2i3rnc",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343e3a9dbb7a90e1dcb5b6.vtt",
- "transcript_text": " Lighthouse, another fellow contributing to Lighthouse consensus client, this time integrating the logging framework tracing into Lighthouse. So thanks for being here. Yeah, go ahead. Hello, everyone. So, first of all, let me say this, that my project isn't that cool. It's kind of like tedious and large-sized chore. You guys will get to witness many cool projects, so I'll just keep my",
- "eventId": "devcon-7",
- "slot_start": 1731474900000,
- "slot_end": 1731475800000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1RQXvuQDzdyRtC3YArjUnvZw9pKG8y3WwlKPipk1FNJE",
- "resources_slides": null,
"speakers": [
- "sayan"
- ]
+ "marek-olszewski"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731580800000,
+ "slot_end": 1731581400000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/14jswR8SSkWsHdCj5ky0DG_01yQVUwV7nJtS5K18ynHg"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -798949,6 +797255,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -799077,42 +797384,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -799169,7 +797440,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -799206,6 +797476,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -799232,6 +797503,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -799257,6 +797529,7 @@
0,
2,
0,
+ 2,
0,
0,
0,
@@ -799267,6 +797540,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -799327,6 +797601,23 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -799694,27 +797985,47 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 2,
2,
0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 0,
+ 0,
+ 0,
2,
0,
0,
@@ -799733,61 +798044,49 @@
},
{
"session": {
- "id": "transaction-simulation-the-good-the-bad-and-the-ugly",
- "sourceId": "TE9JUF",
- "title": "Transaction simulation, the good, the bad & the ugly",
- "description": "Transaction simulation allows users to preview the outcomes of signing a transaction, enabling them to make informed decisions rather than fully trusting the dApp. However, several caveats and risks are associated with relying on simulated transaction outcomes. State changes, differing contract behavior between simulation and on-chain execution, and randomness can all affect the outcome. In this talk, I'll share my experiences and learnings from simulating user transactions over the past 2 years",
- "track": "Security",
+ "id": "trust-minimized-p2p-marketplaces-on-ethereum",
+ "sourceId": "YPNBE8",
+ "title": "Trust-minimized P2P marketplaces on Ethereum",
+ "description": "Blockchains have enabled trustless and fast transaction settlement (i.e. stablecoins, DeFi). However, these existing use cases exist in parallel and are siloed off from the real world. With the maturation of ZK, MPC and other programmable crypto techniques, we are now able to connect data on the internet to blockchains in a trust minimized way for use in smart contracts. This talk will explore the massive design space unlocked for apps (i.e. trust minimized P2P marketplaces)",
+ "track": "Real World Ethereum",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Security",
- "User Experience",
- "safety",
- "Security",
- "User Experience"
- ],
"keywords": [
- "simulation",
- "wallet",
- "safety"
+ "TLSNotary",
+ "ZKEmail",
+ "P2P marketplaces"
+ ],
+ "tags": [
+ "ZKP",
+ "Signatures",
+ "P2P finance",
+ "p2p",
+ "marketplace",
+ "P2P finance",
+ "Signatures",
+ "ZKP"
],
- "duration": 458,
"language": "en",
- "sources_swarmHash": "1367b463e69cb498817ffc03a9949daeade7c14957d466768d66c65a2b542e0f",
- "sources_youtubeId": "12uW2nhIxN4",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67333e6c3a168eb53500581d.vtt",
- "transcript_text": " Hello everyone. My name is Shi, and I'm a security engineer at Fasen. And for the past year, we have been digging into the Amoeba world, so we have some insights to share to bring some new methodologies into this world. And the topic is how to front-run a transaction in the future. So in 2023, we have seen a lot of front-runners have rescued millions of dollars in the hack incidents. For example, they rescued 5.4 million, and also BlockSec. And also in the Khyber-Swab incident, they rescued 5.7 million and returned those funds to the protocols. These are like white hat hackers. But we are seeing a declining trend for this in 2024. And there are some reasons for that. So before that, let me go over about the background of MEV and front-running. So this is how a transaction's lifecycle. So on the top, you can see when the user wants to send the transaction, he wants to send it to the builder first, then the validator. Then the validator will propose a block and commit it to the chain. But if there is a frontrunner, when the user sends a transaction to the builder, the frontrunner will see this transaction. And when he detects this transaction is profitable, he'll replace the beneficiary to himself, and then add a little bit more gas onto that. So the builder will place his transaction in front of the normal transaction. So the user's transaction his transaction in front of the normal transaction. So the user's transaction will be reverted. So the frontrunner will gain profit from this. So then the role of private mempool came. They say we will keep transaction private. And this is beneficiary for most parties. First, arbitrage are fair. Like, at MVVBoss, they want to balance the pools. They find a better swap path win. And also, users, they don't need to suffer from sandwiches. And also, the side effect of this is that hackers transactions, they are protected by the private pool as well. For example, in the previous examples, those frontrunners are not able to frontrun with a private transaction. And is frontrunning dead? And we found the answer to this question is no, not on the block level. Let me explain that. So we have seen a lot of patterns like this. It's called a two-phase style attack. So first, if a hacker wants to hack something, he will first deploy a assistant contract and do some preparation. And finally, he'll send another transaction to trigger the vulnerable function of the victim. So to exploit it, all a map bot or a frontrunner needs to do is to extract all the functions of a contract by using the function signatures and call every function. And if it happens to be the trigger function, a contract by using the function signatures and call every function. And if it happens to be the trigger function, a frontrunner will be able to frontrun this transaction that has never been sent to the builder before. And so it becomes a cat and mouse game between the MEV bots and hackers. And hackers, they thought of some better strategies to protect their contracts. For example, here we have address verification. Basically, it's easy to bypass. All a bot needs to do is to add some hints. And also, if it has an authentication, like here you have a hash of some address. If it's compared to a fixed hash. But all a bot needs to do is to change that equal sign to a not equal sign. And also, then hackers thought of some more sophisticated methods. For example, they hide the parameter to the vulnerable function directly in the parameter in the function. And we found that the goal is really to find the input to trigger a profitable path in the contract because it's already in this contract. And fuzzing is a good tool to do that. So what is fuzzing? It's basically generate a random input. This random is not really random. And then it executes the program, observe and analyze the execution, collect interesting information. And if it's a profitable path, we will exit. Otherwise, we repeat using the collected information. And there are different purposes for fuzzing. In Web 2, you might be corrupting some memory. In Web 3, all this space, it might be breaking some invariants. And here, we are really to find a profitable path. So the effects really depends on the input generation. Here are some heuristic functions or generation methods we want to offer you. And the important thing is about the heuristic functions. These are the that makes the fuzzing different. And there are some pros and cons to fuzzing. For example, it's fast, accurate, and easy to build a prototype. And also, for the cons, it can be time consuming, especially in some chains that have a very low block time interval. And what we want to promote is that I think we should bring more Web 2.0 methodologies into Web 3.0. For example, we haven't seen static analysis, something like that. We're bringing fuzzing, also adding some tint analysis and symbolic execution into our engine. And yeah, we're hoping to see more of this. And that's the end of my talk. I'm ready to take any questions. Thank you so much, Qi. Any questions? The last chance to ask questions before the end of today. Anyone wants to give a go? No questions? Okay. Thank you, Chi. And that wraps up the day of Lightning Talks. What an incredible series we had today. And thanks for attending and all our speakers. And tomorrow we'll continue. So hopefully see you tomorrow. Thank you. you",
- "eventId": "devcon-7",
- "slot_start": 1731409800000,
- "slot_end": 1731410400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Bl4qs4Zj65LUtt4i8uht8GdKLHGxRkYht0gt_Qcd_n4",
- "resources_slides": null,
"speakers": [
- "kim-persson"
- ]
+ "richard"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731556200000,
+ "slot_end": 1731556800000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1_yxVcYnivrcVQGtbD7FmPQLfgJn75M9f-qQDTJJuPH8"
},
"vector": [
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -799913,6 +798212,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -800455,7 +798755,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -800527,7 +798826,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -800543,7 +798841,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -800607,6 +798904,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -800623,6 +798921,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -801059,6 +799358,9 @@
0,
0,
0,
+ 2,
+ 2,
+ 0,
0,
0,
0,
@@ -801092,11 +799394,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -801110,35 +799412,44 @@
},
{
"session": {
- "id": "transforming-systems-lessons-from-taiwans-movements",
- "sourceId": "B9EDKY",
- "title": "Transforming Systems: Lessons from Taiwan's Movements",
- "description": "I will talk about the most recent struggles of open source communities in Taiwan, g0v specifically, how da0 has been trying to help in the past year or so, the conclusions we had and what is still missing. g0v has been running bi-monthly hackathons for 10 years now, which has been the key foundation for the community. April this year they stopped due to lack of funding support, we use this as a point of reference and how a web3 oriented subgroup like da0 could have done better, and the future.",
+ "id": "trust-zones-why-daos-will-be-the-best-organizations-ever-created",
+ "sourceId": "R9ENCP",
+ "title": "Trust Zones: Why DAOs will be the best organizations ever created",
+ "description": "This talk introduces the theory of Trust Zones. Every Trust Zone is a unique blend of constraints, reputation requirements, and accountability measures, within which an agent can operate on behalf of an organization to further its goals.\r\n\r\nI will contend that the operational management of all organizations can be described as creating new Trust Zones and adjusting their parameters. And further, that DAOs and other onchain organizations can do this better than any other organizational form.",
"track": "Coordination",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Community",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Ecosystem",
- "Funding",
- "Mainstream"
- ],
"tags": [
- "Civil Resistance",
- "Coordination",
- "Public good"
+ "DAO",
+ "Governance",
+ "trusted",
+ "DAO",
+ "Governance"
],
- "language": "en",
- "speakers": [
- "noah-yeh"
+ "keywords": [
+ "Trust"
],
+ "duration": 505,
+ "language": "en",
+ "sources_swarmHash": "",
+ "sources_youtubeId": "tu6t6GdLyCg",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67346f1e9dbb7a90e1e41835.vtt",
+ "transcript_text": " Thank you. I'm super excited to share this with you. I actually have like 40 emails that I want to get through in 20 minutes, so we're going to have to keep moving. This is mostly not about me. It's going to be about the cypherpunks. But I will have one slide for ZK Sync. A quote from the ZK Credo. The unwavering long-term vision remains advancing personal freedom for all. Let us remain resolute in championing digital self-ownership onward. You can read the full ZK Sync mission statement in Credo online. We believe in it a lot. All right. Moving on. This talk started because I got annoyed. There were too many people on, like, crypto Twitter who were discussing cypherpunks and had clearly, like, no idea what they were talking about. And so instead of badgering them, I'm just politely informing everyone now of what the cypherpunks were really like. So I read every cypherpunk email. I will now pick the best emails and highlight the cypherpunk ideas, culture and worldview so you can see it for yourself. And we're going to read them and learn them together what the cypherpunks were really like. So here's the format for my talk. First of all, shout out to CryptoAnarchyWiki. You can read all of the archived history there if you'd like. The subject line will be at the top, author, day, month, year at the bottom, and then in the middle will be a screenshot. I'll try to narrate it over it if you can't read all of the text if it's too small. So let's begin. First email. How to make an automated remailer in your copious spare time with easy to find and inexpensive software tools you may have lying around. And then the e-mail goes, it's actually, this is just a clip of it, but part way through it says the Perl script in summary strips off the mail header, saving the subject line, rewrites the new header, here's the script and then just puts the Perl script in the e-mail. So when cypherpunks say, like, cypherpunks write code, they, like, from the first email, were already just sharing with each other tools on, like, how to build this stuff. Like, this literally was, like, one of the first emails. Because the next email I have, like, a week later, is I've had a bunch of people ask me about this group and what it's up to. Accordingly, I drafted a small statement of purpose. Please comment, Eric. And the full thing you've probably seen before, this is like the first draft of what becomes the Cypherpunk manifesto. There's like eight different slight variations of all of this. You've probably seen it a bunch of times. In fact, this is probably the only Cypherpunk email you've ever actually seen that wasn't email. The line I like the most from this one is, Cypherpunks know that a widely dispersed system can't be shut down. Very true. Now, so, the lid of this talk is just me highlighting a bunch of emails, so they're gonna kind of be random, but it's gonna overall get across all of the points. So, let's go. We appear to be entering a long-awaited crypto singularity. Tim C. May, in November 1992 1992 listed a bunch of reasons why he thought a crypto singularity was imminent. There was incredible excitement at these topics at hacker conferences. There were several journalists. There were articles in Scientific American on digital cash and quantum cryptography. There's a firestorm of over 500 comments about cryptographic keys. And all of these points are accelerating situation. Things may get very interesting and very sticky in the next several months. So 1992, maybe there wasn't quite a crypto singularity yet, but now today, I think it's funny because we have all the same topics. Thoughts on digital cash from Mark Horowitz about a month later. Said I'd really like to see some sort of digital cash system set up. Three days after that, Carl Barris replied with digital banking file formats, et cetera, here's what I envision a digital bank working like. And how's the bank protocol. And then just starts going through the math. Alice chooses X and R. Alice computes B equals R cubed times F of X mod N. Like three days later, they're just going straight to building digital money right away. They're not messing around. Electronic money legality. The question came up whether it would be legal to issue electronic money or regular money for that matter. Hal Finney says he got a couple history books out of the library to try to learn something on the history of private banknotes. And then the email is like him doing like seven different book reviews that he clearly like all read over the weekend. One of them is George Selgin's book, The Theory of Free Banking, is called The Return to Situation Competitive Note, where each bank would print its own money, and people would use all these different monies freely according to their preferences. I just think it's funny how he read a bunch of books and emailed everyone his thoughts in the summary. White House letter, they were discussing whether they should, like, contact the government at all or just, like, keep building on their own. There's a suggestion from Dr. Zapod that we should simply send our stance on encryption and why it shouldn't be regulated. I think this is a common goal among all cypherpunks on this list. That is, except the NSA folks who are listening in. Timothy C. May, nonetheless, I will never desire censorship for its own sake, and I will always fight to remove conditions which make censorship exigent in the first place. Yeah, the problem is, like, who decides, like, who gets to be censored? And so, very against it from the beginning of the mailing list. Another email about a White House encryption idea. They are not passing out the algorithm. I don't trust anyone to tell me it's secure. Sent from treason at GNU. I'm not a cryptographer, so it wouldn't help me if they gave me the code, but open source adds more trust. So, is Rush Limbaugh giving Clinton shit about wiretap chip? So, someone sent an email to the Cypherpunk mailing list that said, well, I work for a major airline and would be happy to get you his home address if he has a frequent flyer number. And Mark replied, excuse me, are you completely missing the point here? We're fighting for privacy. Misusing your position in whatever airline you work at for broadcasting someone's home address is completely unethetical to what we're trying to do. So I'm showing you the best of the best e-mails, but there's also people sending emails who have, like, almost no alignment with what the cypherpunks, like, you would think of today. Like, somebody's, like, working in an airline company trying to dox people and, like, mailing the cypherpunk mailing list for some reason. Reply on digital cash. I thought this email was super funny. So someone sent a question, what's to keep someone from opening a digital bank and taking the money and running? And Duncan Frisco replied, nothing. So I think this is the first example of cryptocurrency rugging. But yeah, good luck. Radical paranoia. This one just kind of felt relatable. The end question, am I being paranoid or is there a valid issue here? It's about cryptographic key signing and with PGP back in the 90s you would physically meet someone in person and then sign that their public key actually belongs to them and then he has a problem with doing this online because you can't be completely sure you're talking to the right other person and so I kind of appreciate the thought analysis here of being super paranoid about how these things are going to work. Secure software, secure voice software issues. There are problems yet to be solved. I'm rapidly coming to the conclusion that the only way around the SLIP slash PPP modem buffer delay problems is to speak raw synchronous data to any of the modems, even to the point of implementing v.42bis and HDLC in the host computer instead of using the modem's implementation. I have no idea what most of that means, but it kind of sounds like a lot of core devs when they talk about stuff. And so, yeah, I just thought that was like a fun parallel to today of like, yeah, I'm coming to this conclusion, guys. I think everyone agrees on here, right? Digital warfare. L. Detweiler sent an email that we may see the creation of virtual governments in which geographical location of an individual is irrelevant to the choice of government and perhaps for the first time in history, the individual can choose freely among all that exist to that which best suits his preferences, and the so-called social contract between the citizen and his government is actually made explicit for the first time. This will happen on all levels. And we're beginning to realize what communication truly entails. Now, L. Detweiler is kind of a bit of a character. He's going to come back in a few seconds. Paul Ferguson sent first, Don Henson, I guess, sent an email and said if there's no cypherpunks cause or movement please let me know. Being able to interact with people who believe in the cypherpunks cause is the only reason I subscribe to this list and if there is no cause I'd like to unsubscribe and spend my time elsewhere. And the reply is just what the hell are you talking about? Because imagine being in peak cypherpunk mailing list. Tim May and Hal Finney and Nick Szabo are sending emails every single week. And there's somebody in here who's just like, is there a cause? Does anyone know? Is there a movement? And the reply is just like, what are you talking about? Because some people just can't get the point. I don't know. This is LD. It is LDettweiler. Just a reply to LDettweiler's last flame of me. I won't say that he's insane or deranged since I know that does no good. I won't say that he is raving or frothing at the mouth since that does no good either. So some of the emails kind of get a little bit heated. And Detweiler is basically mad that everyone starts thinking that everyone hates him and curses him. And I continually sent out some of my most masterful and brilliant postings when I still have respectable reputation. Despite that, P. Metzger was continually attacking and dogging me in the most vicious way a human being, at least I think he's a human being. So they're really like, it sounds like crypto Twitter. It's ridiculous. It's hilarious. And Anon replied, but this is probably L. Detweiler again, to Nick Szabo, who Nick Szabo nicely wrote, no, Mr. Detweiler, I'm not pseudo-spoofing. It's not clear what this term means. Detweiler just kind of made it up and got paranoid. But Detweiler replied and said that to Nick Szabo, frankly, I think you're a bald-faced liar. Are you intellectually challenged, or am I going to have to root up all the archives to prove it? I think this is very entertaining to ask Nick Szabo himself if he's intellectually challenged. So all of this drama with Detweiler kind of came to a bit of a conclusion with Timothy C. May writing a summary email of who is L. Detweiler. He joined the cypherpunks list about a year ago, showed great enthusiasm and energy, volunteering to write an FAQ on anonymity and the internet and privacy and anonymity. He put this out very quickly. Email goes on. By the end of it, he has to be removed from the Cypherpunks list and was. He created his own group, the Cypher wonks list, with fascist rules and regulations about true identities, the evils of pseudo spoofing, et cetera. I gather from reports that's now moribund, I didn't join for obvious reasons. And so this was almost the end of Eldette Weiler, except three days later he responded with who is Timothy C. May. And he says, first, reports of my insanity are greatly exaggerated. And I think that's one of the funniest opening lines to an email I've ever seen. And then he has some shots back at Timothy C. Mays, incapable of understanding the distinction between truth and satire. So the drama goes on within the email list. Here, black net is probably what we would call a darknet today. The darknet could remove most of the risk with near perfect anonymity and digital cache. A tidy side income could be created for anyone with access to classified information. This is from Hal Finney. Digital cache, anonymity at the same time. Hal Finney sent a lot of emails about this. Another reply, Hal Finney wrote more, the other issue which I know less about is the possibility of cryptographically strong obfuscated code. For the cryptographers in the audience, you know that's like something we're still kind of working on today but is potentially possible. But the fun part is that Timothy C. May replied that the similarities with zero knowledge work are apparent. In zero knowledge interactive proof systems, one knows something without actually showing what one knows. So sent in March 1994, cyberpunks were already talking about zero-knowledge proofs. NSA digital cash. Yeah, this brings up some serious issues. I doubt it will be long before there are some official government agencies developing official U.S. digital cash system. In fact, it wouldn't surprise me if there are divisions in the NSA dedicated to doing it this moment in April 1994. Cypherpunk's goals. Bad debate drives out good debate. Timothy C. May, he was kind of like almost a moderator for the list a little bit. I mean, the list is unmoderated, but he'd just send like kind of polite rants every once in a while like this. Where he said, we have to stop the slide into inconsequential chatter and paranoid speculation. There's work to be done. I know of no other group even one-tenth as prepared as we are to do this work. Let's get on with it. Tim May. Tim. Delayed self decrypting messages. Paul asked is there a way I can send out a file and perhaps a tool such that the file can be decrypted only after a given date. Now we call this time lock encryption. It barely exists now. It's still a very cool technology that I don't see used very much. But it's another part of cool cryptography that the cypherpunks were trying to think about and discuss, but they didn't quite have all of the cryptography we have now. So, fun to see all of the ideas that are now relevant. I've been showing a lot of highlights of the more chatty stuff, but the whole time there's also very technical conversations always happening. This person has optimized counting bits on a uniprocessor machine and has shared the three opcodes that you need for whichever systems those are. So the technical work did continue. I'm just not showing you lines of code in every single slide. Remailer chaining results. How Phinney sent an email in August 1994. I've done some calculations on the mixing properties of CHOM-style networks and gotten some interesting results, and then wrote, like, four pages straight of computations on, like, mixed nets and the privacy properties and trade-offs between different parameters. And then he ends his email with, now, how many people have read this far. Not me. I didn't even read it for this talk. Okay. Social punishment reputation systems. I think actually there's an interesting point in the first paragraph where it says the decentralized system makes it very difficult for someone to rejoin society to have his or her reformation recognized. The channels in traditional societies include good work and being a good citizen. The other is just starting a new identity. And the mixed proposal is a strong case for universal pseudonymity. Ban true names. Maybe a little aggressive. Which together with a strong voluntary reputation and social punishment systems can form the basis for the cyberspatial order. Kind of ambitious. I like the banning true names idea. Bruce Schneier is a famous cryptographer a lot of you might recognize. He wrote the book that a lot of the cypherpunks were studying at the time. He was also sending emails on how to help design cryptography systems, including on Faisal networks, S boxes, and block cipher design. Good S box design, not an easy task, and he outlines four different ways of choosing randomly, testing, man made, math made. They're all kind of teaching each other how cryptography works at the same time. I think this was nice because this was literally like his published paper. Academia used to be much easier to read back then, and I wish we would have more papers that are like this level of explanation, please. Cell phone security, Conrad Walton. I feel like this is just a very on brand of what you imagine like a cypherpunk anarchist email would sound like. As one who owns an AOR 1000 radio frequency scanner that can receive any and all cell phone conversations, I would have to say that you have no security unless you have some kind of voice encryption. Later on, I bought guns with high capacity magazines this year after they were banned also. I wish I had enough money to buy a good assault rifle before they're all overpriced. Parentheses, they'll never be gone, just overpriced. Conrad Walton. So, yeah, super on-brand. Timothy May is right. This is, there ends up being, like, more drama in the mailing list. Eric Hughes and Timothy May were kind of two of, like, the big founders originally. They're the ones, like, you see on the magazine cover of Wired. But basically, like, there's kind of a falling out. Eric Hughes is maybe embodying the dictatorial approach he claims to defy via cypherpunk philosophy, hypocritical and egomaniacal. And so even people who maybe started out as cypherpunks end up getting accused of, like, yeah, being dictators? So maybe it's hard to get along for a long time. Value of anonymity. It's easy to imagine the sort of panopticon which will soon arise in the internet and its descendants unless the strongest possible protections are adopted. And I thought this e-mail was funny because it's from Wadeye. And he's like talking about a new encryption system and says, I can try, but I've never done real crypto programming before. But if you know now, like, Wei Dai is a legend in cryptography. And so, like, even legends started out, you know, at simple things. Here's a list of attempts to ban encryption in 1997, 1981, 1984, 1986, 1987, 1989, 1990. In 1991, there's one I want to highlight. The FBI asked Senator Joe Biden to introduce a sense of Congress to recommend backdoors in all encryption telephone systems, and the provision was removed after public outcry. 1992, 1993, and the email sent in 1995. So it's like almost every single year they were introducing new proposals in Congress to ban cryptography or install backdoors. This was a real large threat at the time. And I think we haven't needed to worry about it too much recently, but hopefully this never seriously comes back. Crypto could be the next wave of IPOs. Timothy May, 1995. It seems that anything involving the internet, the web, and digital commerce is really, really hot. I thought this was fun just because we're talking about Fiat-Shemir. So I like the cryptography part. If you're into ZK still, this is not the same Z this is not the same paper, but still the same cryptographers on how to prove themselves. Crypto hardware summary. Douglas Barnes in 1995 pointed out that using coprocessors to achieve speed in cryptography operations is probably not justifiable for end users. It is almost always justified for servers with high volume. And then people, though, running cryptography-based transaction clients on their PCs are going to learn, one way or another, that having valuable secret keys on their hard disks is not a great idea. This, not speed, is the primary motivation for consumer-oriented cryptography hardware. Yeah, so they already thought of everything, like back in 1995. Cypherpunk FAQ, we're almost done. I downloaded the Cypherpunk FAQ from the Cypherpunk mailing list. When I decompressed it, all it contained were the words, Yoo-hoo, anybody home? Has the FAQ been corrupted, or is this an inside joke? Yeah, so apparently it was from L.Weiler. Yeah, it was a joke. And then this is the last e-mail that I'll share is someone invited the entire Cypherpunks mailing list to their birthday party, which is a great idea in the first place. And Julian Assange pointed out that if the party ends at 10 p.m., that's not a party, that's an after school Tupperware get together. Cool. So now you've seen the Cypherpunk emails, what you do with this information. Really whatever you want. I just wanted people to be informed on, like, sort of what it was like. And with that, we'll go to Q&A. So thank you. Ooh. Big applause for Porter. Yeah. For the Q&A, you know how it goes. You can scan that QR code and then register. We have some questions already. What are some ideas early cypherpunks had that have yet to be implemented or maybe are implemented but less popular than P2P cache or Tor? Yeah, so I think one thing is the cypherpunks were even more paranoid than we are now and they were very concerned about verifiable hardware and building hardware that you could actually know that the code is running correctly. I think that's one of the things. Besides that, there were just a bunch of the cryptography ideas that are now called time lock encryption and witness encryption and super advanced stuff that's not even quite here today. But yeah, it was cool. Alright, next questions. What are some yet-to-be mainstream Extropian prophecies? I'm not sure. I mean, they talk, there's just a lot of stuff in the emails. I don't know if I have any good prophecies that they were predicting. Most of their prophecies were that there's all the ways the Doomers who think everything's going to get banned and we're going to need to build BunkerCoin and this is our only hope is to build cryptography and surprisingly like governments have somewhat gotten on board probably a little more than they expected. Right then the top one it seems like people are very interested in those slides so how do can they get those slides? Yeah I'll post all of the slides afterwards also yeah the slides don't have like every email so maybe I'll include some extras. All right. And then I like that one on the bottom also. That was very interesting to see what these early people discussed. So where are these conversations... Where did that go? Yeah, here. Where are those good conversations happening nowadays? I mean, probably like crypto Twitter, like ETH research forums, like places like this conference actually. If you want to be discussing these topics, there are tons of people, probably literally right here, who are happy to talk about these with you. Okay, now we go to the bottom, the good questions. So what everybody wants to know, reading through all these emails, any guess who is Satoshi? So actually, I'm going to cop out, but I'm super against Satoshi guessing. I'm very adamant that we should just leave Satoshi as anonymous and not try and figure out who it is. There's probably text analysis you could start doing on his emails versus some of the Cypherpunk emails and things, but I'd rather not know.",
"eventId": "devcon-7",
- "slot_start": 1731638700000,
- "slot_end": 1731639900000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1mKMsPFBtVYtAcJOczCaTR2Ssw6fiQ86zw-Jz3zyGmFk"
+ "slot_start": 1731488400000,
+ "slot_end": 1731489000000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/11gK41qto_r77F_waBaxEdW2JoYIgXHs4mVHzUzI_OaU",
+ "resources_slides": null,
+ "speakers": [
+ "spencer-graham"
+ ]
},
"vector": [
0,
@@ -801819,9 +800130,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -801989,10 +800297,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -802002,7 +800312,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -802048,7 +800357,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -802065,6 +800373,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -802123,7 +800432,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -802454,16 +800762,16 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -802476,58 +800784,49 @@
},
{
"session": {
- "id": "transitioning-from-an-l1-to-an-l2-a-case-study",
- "sourceId": "KHVZ9M",
- "title": "Transitioning from an L1 to an L2: A case study",
- "description": "This talk will cover the learnings from cLabs' experience rebuilding Celo from the ground up as an L2. We hope that it can be a useful case study for other L1s to follow.",
- "track": "Layer 2",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "try-it-out-in-remix",
+ "sourceId": "SUEJQR",
+ "title": "Try it out in Remix",
+ "description": "Remix is great for your blockchain experiments for both new Web3 devs and OGs. We’ll present the new Remix Desktop - great for offline work, plus RemixAI tools and RemixZK tools, our new collection of templates, our new video guide, our new tool to make a basic DApp - great for hackathons, and more! Learn to play in Remix!",
+ "track": "Developer Experience",
+ "type": "Talk",
+ "expertise": "Beginner",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Layer2",
- "case study",
- "technical learnings"
+ "AI"
],
"tags": [
- "Layer 1",
"Layer 2s",
- "Rollups",
- "Scalability",
- "Optimistic rollups",
- "Use Cases",
- "learnings",
- "technical",
- "Layer 1",
+ "Tooling",
+ "DevRel",
+ "Desktop",
+ "ai",
+ "Desktop",
+ "DevRel",
"Layer 2s",
- "Optimistic rollups",
- "Rollups",
- "Scalability",
- "Use Cases"
+ "Tooling"
],
"language": "en",
"speakers": [
- "marek-olszewski"
+ "rob-stupay"
],
"eventId": "devcon-7",
- "slot_start": 1731580800000,
- "slot_end": 1731581400000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/14jswR8SSkWsHdCj5ky0DG_01yQVUwV7nJtS5K18ynHg"
+ "slot_start": 1731582000000,
+ "slot_end": 1731583800000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1frNEqhlzbsXj_EqKtcIYr8R8G-t4ymlj401WFG6BBYw"
},
"vector": [
0,
0,
0,
+ 6,
0,
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -803066,7 +801365,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -803200,6 +801498,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -803285,12 +801584,12 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -803312,7 +801611,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -803338,7 +801636,8 @@
0,
2,
0,
- 2,
+ 0,
+ 0,
0,
0,
0,
@@ -803410,7 +801709,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -803444,6 +801742,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -803799,7 +802099,6 @@
0,
0,
0,
- 2,
2,
0,
0,
@@ -803831,6 +802130,7 @@
0,
0,
0,
+ 0,
2,
0,
0,
@@ -803846,57 +802146,49 @@
0,
0,
0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "trust-minimized-p2p-marketplaces-on-ethereum",
- "sourceId": "YPNBE8",
- "title": "Trust-minimized P2P marketplaces on Ethereum",
- "description": "Blockchains have enabled trustless and fast transaction settlement (i.e. stablecoins, DeFi). However, these existing use cases exist in parallel and are siloed off from the real world. With the maturation of ZK, MPC and other programmable crypto techniques, we are now able to connect data on the internet to blockchains in a trust minimized way for use in smart contracts. This talk will explore the massive design space unlocked for apps (i.e. trust minimized P2P marketplaces)",
- "track": "Real World Ethereum",
+ "id": "txain-discover-the-next-generation-of-blockchain-exploration",
+ "sourceId": "WRGHRM",
+ "title": "TXain: Discover the Next Generation of Blockchain Exploration",
+ "description": "Discover TXain, the next generation blockchain explorer designed to elevate your blockchain experience. Join us as we delve into our key features: an intuitive UI, real-time data, advanced search capabilities, and in-depth analytics. As a new startup, we’re committed to performance and information clarity, ensuring seamless navigation and comprehensive insights. Learn how TXain is set to redefine blockchain exploration, providing the tools you need to explore, analyze, and understand the blockch",
+ "track": "Developer Experience",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Product",
+ "expertise": "Beginner",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "TLSNotary",
- "ZKEmail",
- "P2P marketplaces"
+ "blockchain explorer",
+ "user experience",
+ "Real-Time Data"
],
"tags": [
- "ZKP",
- "Signatures",
- "P2P finance",
- "p2p",
- "marketplace",
- "P2P finance",
- "Signatures",
- "ZKP"
+ "data",
+ "real-time"
],
"language": "en",
"speakers": [
- "richard"
+ "joan-baylina",
+ "daniel"
],
"eventId": "devcon-7",
- "slot_start": 1731556200000,
- "slot_end": 1731556800000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1_yxVcYnivrcVQGtbD7FmPQLfgJn75M9f-qQDTJJuPH8"
+ "slot_start": 1731493200000,
+ "slot_end": 1731493800000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1_ATKYtQF_Q_hjc85bqwcab990AdWWjiO8FiSDVR2BMg"
},
"vector": [
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -804022,7 +802314,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -804056,6 +802347,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -804570,6 +802862,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -804716,7 +803009,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -804733,7 +803025,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -804940,7 +803231,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -804951,6 +803241,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -805173,7 +803464,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -805202,15 +803492,15 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -805224,44 +803514,29 @@
},
{
"session": {
- "id": "trust-zones-why-daos-will-be-the-best-organizations-ever-created",
- "sourceId": "R9ENCP",
- "title": "Trust Zones: Why DAOs will be the best organizations ever created",
- "description": "This talk introduces the theory of Trust Zones. Every Trust Zone is a unique blend of constraints, reputation requirements, and accountability measures, within which an agent can operate on behalf of an organization to further its goals.\r\n\r\nI will contend that the operational management of all organizations can be described as creating new Trust Zones and adjusting their parameters. And further, that DAOs and other onchain organizations can do this better than any other organizational form.",
- "track": "Coordination",
+ "id": "txmonster-mud-day-demo",
+ "sourceId": "3GSMUH",
+ "title": "TxMonster - MUD Day Demo",
+ "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications\r\n\r\nUsing MUD Dev to build \"Eat Sleep & Survive\" TxMonster on RedStone Chain",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
"type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "DAO",
- "Governance",
- "trusted",
- "DAO",
- "Governance"
- ],
"keywords": [
- "Trust"
+ "N/A"
],
- "duration": 505,
+ "tags": [],
"language": "en",
- "sources_swarmHash": "",
- "sources_youtubeId": "tu6t6GdLyCg",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67346f1e9dbb7a90e1e41835.vtt",
- "transcript_text": " Thank you. I'm super excited to share this with you. I actually have like 40 emails that I want to get through in 20 minutes, so we're going to have to keep moving. This is mostly not about me. It's going to be about the cypherpunks. But I will have one slide for ZK Sync. A quote from the ZK Credo. The unwavering long-term vision remains advancing personal freedom for all. Let us remain resolute in championing digital self-ownership onward. You can read the full ZK Sync mission statement in Credo online. We believe in it a lot. All right. Moving on. This talk started because I got annoyed. There were too many people on, like, crypto Twitter who were discussing cypherpunks and had clearly, like, no idea what they were talking about. And so instead of badgering them, I'm just politely informing everyone now of what the cypherpunks were really like. So I read every cypherpunk email. I will now pick the best emails and highlight the cypherpunk ideas, culture and worldview so you can see it for yourself. And we're going to read them and learn them together what the cypherpunks were really like. So here's the format for my talk. First of all, shout out to CryptoAnarchyWiki. You can read all of the archived history there if you'd like. The subject line will be at the top, author, day, month, year at the bottom, and then in the middle will be a screenshot. I'll try to narrate it over it if you can't read all of the text if it's too small. So let's begin. First email. How to make an automated remailer in your copious spare time with easy to find and inexpensive software tools you may have lying around. And then the e-mail goes, it's actually, this is just a clip of it, but part way through it says the Perl script in summary strips off the mail header, saving the subject line, rewrites the new header, here's the script and then just puts the Perl script in the e-mail. So when cypherpunks say, like, cypherpunks write code, they, like, from the first email, were already just sharing with each other tools on, like, how to build this stuff. Like, this literally was, like, one of the first emails. Because the next email I have, like, a week later, is I've had a bunch of people ask me about this group and what it's up to. Accordingly, I drafted a small statement of purpose. Please comment, Eric. And the full thing you've probably seen before, this is like the first draft of what becomes the Cypherpunk manifesto. There's like eight different slight variations of all of this. You've probably seen it a bunch of times. In fact, this is probably the only Cypherpunk email you've ever actually seen that wasn't email. The line I like the most from this one is, Cypherpunks know that a widely dispersed system can't be shut down. Very true. Now, so, the lid of this talk is just me highlighting a bunch of emails, so they're gonna kind of be random, but it's gonna overall get across all of the points. So, let's go. We appear to be entering a long-awaited crypto singularity. Tim C. May, in November 1992 1992 listed a bunch of reasons why he thought a crypto singularity was imminent. There was incredible excitement at these topics at hacker conferences. There were several journalists. There were articles in Scientific American on digital cash and quantum cryptography. There's a firestorm of over 500 comments about cryptographic keys. And all of these points are accelerating situation. Things may get very interesting and very sticky in the next several months. So 1992, maybe there wasn't quite a crypto singularity yet, but now today, I think it's funny because we have all the same topics. Thoughts on digital cash from Mark Horowitz about a month later. Said I'd really like to see some sort of digital cash system set up. Three days after that, Carl Barris replied with digital banking file formats, et cetera, here's what I envision a digital bank working like. And how's the bank protocol. And then just starts going through the math. Alice chooses X and R. Alice computes B equals R cubed times F of X mod N. Like three days later, they're just going straight to building digital money right away. They're not messing around. Electronic money legality. The question came up whether it would be legal to issue electronic money or regular money for that matter. Hal Finney says he got a couple history books out of the library to try to learn something on the history of private banknotes. And then the email is like him doing like seven different book reviews that he clearly like all read over the weekend. One of them is George Selgin's book, The Theory of Free Banking, is called The Return to Situation Competitive Note, where each bank would print its own money, and people would use all these different monies freely according to their preferences. I just think it's funny how he read a bunch of books and emailed everyone his thoughts in the summary. White House letter, they were discussing whether they should, like, contact the government at all or just, like, keep building on their own. There's a suggestion from Dr. Zapod that we should simply send our stance on encryption and why it shouldn't be regulated. I think this is a common goal among all cypherpunks on this list. That is, except the NSA folks who are listening in. Timothy C. May, nonetheless, I will never desire censorship for its own sake, and I will always fight to remove conditions which make censorship exigent in the first place. Yeah, the problem is, like, who decides, like, who gets to be censored? And so, very against it from the beginning of the mailing list. Another email about a White House encryption idea. They are not passing out the algorithm. I don't trust anyone to tell me it's secure. Sent from treason at GNU. I'm not a cryptographer, so it wouldn't help me if they gave me the code, but open source adds more trust. So, is Rush Limbaugh giving Clinton shit about wiretap chip? So, someone sent an email to the Cypherpunk mailing list that said, well, I work for a major airline and would be happy to get you his home address if he has a frequent flyer number. And Mark replied, excuse me, are you completely missing the point here? We're fighting for privacy. Misusing your position in whatever airline you work at for broadcasting someone's home address is completely unethetical to what we're trying to do. So I'm showing you the best of the best e-mails, but there's also people sending emails who have, like, almost no alignment with what the cypherpunks, like, you would think of today. Like, somebody's, like, working in an airline company trying to dox people and, like, mailing the cypherpunk mailing list for some reason. Reply on digital cash. I thought this email was super funny. So someone sent a question, what's to keep someone from opening a digital bank and taking the money and running? And Duncan Frisco replied, nothing. So I think this is the first example of cryptocurrency rugging. But yeah, good luck. Radical paranoia. This one just kind of felt relatable. The end question, am I being paranoid or is there a valid issue here? It's about cryptographic key signing and with PGP back in the 90s you would physically meet someone in person and then sign that their public key actually belongs to them and then he has a problem with doing this online because you can't be completely sure you're talking to the right other person and so I kind of appreciate the thought analysis here of being super paranoid about how these things are going to work. Secure software, secure voice software issues. There are problems yet to be solved. I'm rapidly coming to the conclusion that the only way around the SLIP slash PPP modem buffer delay problems is to speak raw synchronous data to any of the modems, even to the point of implementing v.42bis and HDLC in the host computer instead of using the modem's implementation. I have no idea what most of that means, but it kind of sounds like a lot of core devs when they talk about stuff. And so, yeah, I just thought that was like a fun parallel to today of like, yeah, I'm coming to this conclusion, guys. I think everyone agrees on here, right? Digital warfare. L. Detweiler sent an email that we may see the creation of virtual governments in which geographical location of an individual is irrelevant to the choice of government and perhaps for the first time in history, the individual can choose freely among all that exist to that which best suits his preferences, and the so-called social contract between the citizen and his government is actually made explicit for the first time. This will happen on all levels. And we're beginning to realize what communication truly entails. Now, L. Detweiler is kind of a bit of a character. He's going to come back in a few seconds. Paul Ferguson sent first, Don Henson, I guess, sent an email and said if there's no cypherpunks cause or movement please let me know. Being able to interact with people who believe in the cypherpunks cause is the only reason I subscribe to this list and if there is no cause I'd like to unsubscribe and spend my time elsewhere. And the reply is just what the hell are you talking about? Because imagine being in peak cypherpunk mailing list. Tim May and Hal Finney and Nick Szabo are sending emails every single week. And there's somebody in here who's just like, is there a cause? Does anyone know? Is there a movement? And the reply is just like, what are you talking about? Because some people just can't get the point. I don't know. This is LD. It is LDettweiler. Just a reply to LDettweiler's last flame of me. I won't say that he's insane or deranged since I know that does no good. I won't say that he is raving or frothing at the mouth since that does no good either. So some of the emails kind of get a little bit heated. And Detweiler is basically mad that everyone starts thinking that everyone hates him and curses him. And I continually sent out some of my most masterful and brilliant postings when I still have respectable reputation. Despite that, P. Metzger was continually attacking and dogging me in the most vicious way a human being, at least I think he's a human being. So they're really like, it sounds like crypto Twitter. It's ridiculous. It's hilarious. And Anon replied, but this is probably L. Detweiler again, to Nick Szabo, who Nick Szabo nicely wrote, no, Mr. Detweiler, I'm not pseudo-spoofing. It's not clear what this term means. Detweiler just kind of made it up and got paranoid. But Detweiler replied and said that to Nick Szabo, frankly, I think you're a bald-faced liar. Are you intellectually challenged, or am I going to have to root up all the archives to prove it? I think this is very entertaining to ask Nick Szabo himself if he's intellectually challenged. So all of this drama with Detweiler kind of came to a bit of a conclusion with Timothy C. May writing a summary email of who is L. Detweiler. He joined the cypherpunks list about a year ago, showed great enthusiasm and energy, volunteering to write an FAQ on anonymity and the internet and privacy and anonymity. He put this out very quickly. Email goes on. By the end of it, he has to be removed from the Cypherpunks list and was. He created his own group, the Cypher wonks list, with fascist rules and regulations about true identities, the evils of pseudo spoofing, et cetera. I gather from reports that's now moribund, I didn't join for obvious reasons. And so this was almost the end of Eldette Weiler, except three days later he responded with who is Timothy C. May. And he says, first, reports of my insanity are greatly exaggerated. And I think that's one of the funniest opening lines to an email I've ever seen. And then he has some shots back at Timothy C. Mays, incapable of understanding the distinction between truth and satire. So the drama goes on within the email list. Here, black net is probably what we would call a darknet today. The darknet could remove most of the risk with near perfect anonymity and digital cache. A tidy side income could be created for anyone with access to classified information. This is from Hal Finney. Digital cache, anonymity at the same time. Hal Finney sent a lot of emails about this. Another reply, Hal Finney wrote more, the other issue which I know less about is the possibility of cryptographically strong obfuscated code. For the cryptographers in the audience, you know that's like something we're still kind of working on today but is potentially possible. But the fun part is that Timothy C. May replied that the similarities with zero knowledge work are apparent. In zero knowledge interactive proof systems, one knows something without actually showing what one knows. So sent in March 1994, cyberpunks were already talking about zero-knowledge proofs. NSA digital cash. Yeah, this brings up some serious issues. I doubt it will be long before there are some official government agencies developing official U.S. digital cash system. In fact, it wouldn't surprise me if there are divisions in the NSA dedicated to doing it this moment in April 1994. Cypherpunk's goals. Bad debate drives out good debate. Timothy C. May, he was kind of like almost a moderator for the list a little bit. I mean, the list is unmoderated, but he'd just send like kind of polite rants every once in a while like this. Where he said, we have to stop the slide into inconsequential chatter and paranoid speculation. There's work to be done. I know of no other group even one-tenth as prepared as we are to do this work. Let's get on with it. Tim May. Tim. Delayed self decrypting messages. Paul asked is there a way I can send out a file and perhaps a tool such that the file can be decrypted only after a given date. Now we call this time lock encryption. It barely exists now. It's still a very cool technology that I don't see used very much. But it's another part of cool cryptography that the cypherpunks were trying to think about and discuss, but they didn't quite have all of the cryptography we have now. So, fun to see all of the ideas that are now relevant. I've been showing a lot of highlights of the more chatty stuff, but the whole time there's also very technical conversations always happening. This person has optimized counting bits on a uniprocessor machine and has shared the three opcodes that you need for whichever systems those are. So the technical work did continue. I'm just not showing you lines of code in every single slide. Remailer chaining results. How Phinney sent an email in August 1994. I've done some calculations on the mixing properties of CHOM-style networks and gotten some interesting results, and then wrote, like, four pages straight of computations on, like, mixed nets and the privacy properties and trade-offs between different parameters. And then he ends his email with, now, how many people have read this far. Not me. I didn't even read it for this talk. Okay. Social punishment reputation systems. I think actually there's an interesting point in the first paragraph where it says the decentralized system makes it very difficult for someone to rejoin society to have his or her reformation recognized. The channels in traditional societies include good work and being a good citizen. The other is just starting a new identity. And the mixed proposal is a strong case for universal pseudonymity. Ban true names. Maybe a little aggressive. Which together with a strong voluntary reputation and social punishment systems can form the basis for the cyberspatial order. Kind of ambitious. I like the banning true names idea. Bruce Schneier is a famous cryptographer a lot of you might recognize. He wrote the book that a lot of the cypherpunks were studying at the time. He was also sending emails on how to help design cryptography systems, including on Faisal networks, S boxes, and block cipher design. Good S box design, not an easy task, and he outlines four different ways of choosing randomly, testing, man made, math made. They're all kind of teaching each other how cryptography works at the same time. I think this was nice because this was literally like his published paper. Academia used to be much easier to read back then, and I wish we would have more papers that are like this level of explanation, please. Cell phone security, Conrad Walton. I feel like this is just a very on brand of what you imagine like a cypherpunk anarchist email would sound like. As one who owns an AOR 1000 radio frequency scanner that can receive any and all cell phone conversations, I would have to say that you have no security unless you have some kind of voice encryption. Later on, I bought guns with high capacity magazines this year after they were banned also. I wish I had enough money to buy a good assault rifle before they're all overpriced. Parentheses, they'll never be gone, just overpriced. Conrad Walton. So, yeah, super on-brand. Timothy May is right. This is, there ends up being, like, more drama in the mailing list. Eric Hughes and Timothy May were kind of two of, like, the big founders originally. They're the ones, like, you see on the magazine cover of Wired. But basically, like, there's kind of a falling out. Eric Hughes is maybe embodying the dictatorial approach he claims to defy via cypherpunk philosophy, hypocritical and egomaniacal. And so even people who maybe started out as cypherpunks end up getting accused of, like, yeah, being dictators? So maybe it's hard to get along for a long time. Value of anonymity. It's easy to imagine the sort of panopticon which will soon arise in the internet and its descendants unless the strongest possible protections are adopted. And I thought this e-mail was funny because it's from Wadeye. And he's like talking about a new encryption system and says, I can try, but I've never done real crypto programming before. But if you know now, like, Wei Dai is a legend in cryptography. And so, like, even legends started out, you know, at simple things. Here's a list of attempts to ban encryption in 1997, 1981, 1984, 1986, 1987, 1989, 1990. In 1991, there's one I want to highlight. The FBI asked Senator Joe Biden to introduce a sense of Congress to recommend backdoors in all encryption telephone systems, and the provision was removed after public outcry. 1992, 1993, and the email sent in 1995. So it's like almost every single year they were introducing new proposals in Congress to ban cryptography or install backdoors. This was a real large threat at the time. And I think we haven't needed to worry about it too much recently, but hopefully this never seriously comes back. Crypto could be the next wave of IPOs. Timothy May, 1995. It seems that anything involving the internet, the web, and digital commerce is really, really hot. I thought this was fun just because we're talking about Fiat-Shemir. So I like the cryptography part. If you're into ZK still, this is not the same Z this is not the same paper, but still the same cryptographers on how to prove themselves. Crypto hardware summary. Douglas Barnes in 1995 pointed out that using coprocessors to achieve speed in cryptography operations is probably not justifiable for end users. It is almost always justified for servers with high volume. And then people, though, running cryptography-based transaction clients on their PCs are going to learn, one way or another, that having valuable secret keys on their hard disks is not a great idea. This, not speed, is the primary motivation for consumer-oriented cryptography hardware. Yeah, so they already thought of everything, like back in 1995. Cypherpunk FAQ, we're almost done. I downloaded the Cypherpunk FAQ from the Cypherpunk mailing list. When I decompressed it, all it contained were the words, Yoo-hoo, anybody home? Has the FAQ been corrupted, or is this an inside joke? Yeah, so apparently it was from L.Weiler. Yeah, it was a joke. And then this is the last e-mail that I'll share is someone invited the entire Cypherpunks mailing list to their birthday party, which is a great idea in the first place. And Julian Assange pointed out that if the party ends at 10 p.m., that's not a party, that's an after school Tupperware get together. Cool. So now you've seen the Cypherpunk emails, what you do with this information. Really whatever you want. I just wanted people to be informed on, like, sort of what it was like. And with that, we'll go to Q&A. So thank you. Ooh. Big applause for Porter. Yeah. For the Q&A, you know how it goes. You can scan that QR code and then register. We have some questions already. What are some ideas early cypherpunks had that have yet to be implemented or maybe are implemented but less popular than P2P cache or Tor? Yeah, so I think one thing is the cypherpunks were even more paranoid than we are now and they were very concerned about verifiable hardware and building hardware that you could actually know that the code is running correctly. I think that's one of the things. Besides that, there were just a bunch of the cryptography ideas that are now called time lock encryption and witness encryption and super advanced stuff that's not even quite here today. But yeah, it was cool. Alright, next questions. What are some yet-to-be mainstream Extropian prophecies? I'm not sure. I mean, they talk, there's just a lot of stuff in the emails. I don't know if I have any good prophecies that they were predicting. Most of their prophecies were that there's all the ways the Doomers who think everything's going to get banned and we're going to need to build BunkerCoin and this is our only hope is to build cryptography and surprisingly like governments have somewhat gotten on board probably a little more than they expected. Right then the top one it seems like people are very interested in those slides so how do can they get those slides? Yeah I'll post all of the slides afterwards also yeah the slides don't have like every email so maybe I'll include some extras. All right. And then I like that one on the bottom also. That was very interesting to see what these early people discussed. So where are these conversations... Where did that go? Yeah, here. Where are those good conversations happening nowadays? I mean, probably like crypto Twitter, like ETH research forums, like places like this conference actually. If you want to be discussing these topics, there are tons of people, probably literally right here, who are happy to talk about these with you. Okay, now we go to the bottom, the good questions. So what everybody wants to know, reading through all these emails, any guess who is Satoshi? So actually, I'm going to cop out, but I'm super against Satoshi guessing. I'm very adamant that we should just leave Satoshi as anonymous and not try and figure out who it is. There's probably text analysis you could start doing on his emails versus some of the Cypherpunk emails and things, but I'd rather not know.",
+ "speakers": [
+ "buidltxgames"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731488400000,
- "slot_end": 1731489000000,
+ "slot_start": 1731558000000,
+ "slot_end": 1731558300000,
"slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/11gK41qto_r77F_waBaxEdW2JoYIgXHs4mVHzUzI_OaU",
- "resources_slides": null,
- "speakers": [
- "spencer-graham"
- ]
+ "resources_presentation": "https://docs.google.com/presentation/d/10U4OcgkMv_HGXoZzHe-sIP9e08AcMp-G142YBiu1DUM"
},
"vector": [
0,
@@ -805275,9 +803550,8 @@
0,
0,
0,
- 6,
- 0,
0,
+ 6,
0,
0,
0,
@@ -806112,12 +804386,10 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -806188,7 +804460,7 @@
0,
0,
0,
- 2,
+ 0,
0,
0,
0,
@@ -806599,46 +804871,37 @@
},
{
"session": {
- "id": "try-it-out-in-remix",
- "sourceId": "SUEJQR",
- "title": "Try it out in Remix",
- "description": "Remix is great for your blockchain experiments for both new Web3 devs and OGs. We’ll present the new Remix Desktop - great for offline work, plus RemixAI tools and RemixZK tools, our new collection of templates, our new video guide, our new tool to make a basic DApp - great for hackathons, and more! Learn to play in Remix!",
- "track": "Developer Experience",
- "type": "Talk",
+ "id": "ultimate-dominion-mud-day-demo",
+ "sourceId": "GPQVMW",
+ "title": "Ultimate Dominion - MUD Day Demo",
+ "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nUltimate Dominion is a fully onchain text-based RPG. Explore the world, defeat monsters, collect, buy, and sell items.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "type": "Lightning Talk",
"expertise": "Beginner",
- "audience": "Developer",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "AI"
- ],
+ "keywords": [],
"tags": [
- "Layer 2s",
- "Tooling",
- "DevRel",
- "Desktop",
- "ai",
- "Desktop",
- "DevRel",
- "Layer 2s",
- "Tooling"
+ "Gaming",
+ "Autonomous World",
+ "Autonomous World",
+ "Gaming"
],
"language": "en",
"speakers": [
- "rob-stupay"
+ "ritz-raspa"
],
"eventId": "devcon-7",
- "slot_start": 1731582000000,
- "slot_end": 1731583800000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1frNEqhlzbsXj_EqKtcIYr8R8G-t4ymlj401WFG6BBYw"
+ "slot_start": 1731558300000,
+ "slot_end": 1731558600000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/13Uil3sm_cj9Qi6g5Yd7Wn1eUVWbT6tRsAAUDqNmNTmU"
},
"vector": [
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -806648,6 +804911,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -807407,7 +805671,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -807452,7 +805715,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -807466,7 +805728,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -807497,6 +805758,9 @@
0,
0,
0,
+ 2,
+ 2,
+ 0,
0,
0,
0,
@@ -807560,7 +805824,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -807919,7 +806182,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -807953,9 +806215,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -807969,41 +806231,42 @@
},
{
"session": {
- "id": "txain-discover-the-next-generation-of-blockchain-exploration",
- "sourceId": "WRGHRM",
- "title": "TXain: Discover the Next Generation of Blockchain Exploration",
- "description": "Discover TXain, the next generation blockchain explorer designed to elevate your blockchain experience. Join us as we delve into our key features: an intuitive UI, real-time data, advanced search capabilities, and in-depth analytics. As a new startup, we’re committed to performance and information clarity, ensuring seamless navigation and comprehensive insights. Learn how TXain is set to redefine blockchain exploration, providing the tools you need to explore, analyze, and understand the blockch",
- "track": "Developer Experience",
+ "id": "unchained-index-a-purposefully-designed-schelling-point-a-native-web3-api",
+ "sourceId": "VBUJML",
+ "title": "Unchained Index: A Purposefully Designed Schelling Point: A native Web3 API",
+ "description": "The Unchained Index smart contract, part of TrueBlocks, acts as a purposefully-designed Schelling Point, creating a decentralized, permissionless store for blockchain index data. In this talk, we generalize the Unchained Index to show it can serve as a repository for other datasets such as event signatures and address labels. We contend we can replace costly APIs with a robust, reproducible public good, enhancing data accessibility & decentralization.",
+ "track": "Coordination",
"type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Developer",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "blockchain explorer",
- "user experience",
- "Real-Time Data"
+ "none"
],
"tags": [
- "data",
- "real-time"
+ "Coordination",
+ "Decentralization",
+ "Ethereum for Good",
+ "Coordination",
+ "Decentralization",
+ "Ethereum for Good"
],
"language": "en",
"speakers": [
- "joan-baylina",
- "daniel"
+ "thomas-jay-rush",
+ "meriam-zandi"
],
"eventId": "devcon-7",
- "slot_start": 1731493200000,
- "slot_end": 1731493800000,
+ "slot_start": 1731492000000,
+ "slot_end": 1731492600000,
"slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1_ATKYtQF_Q_hjc85bqwcab990AdWWjiO8FiSDVR2BMg"
+ "resources_presentation": "https://docs.google.com/presentation/d/12qCfXtoD8E9oGVRdfTgU97VfTsXFeb1ceIy1bYwWAV0"
},
"vector": [
0,
0,
0,
- 6,
0,
0,
0,
@@ -808012,6 +806275,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -808166,7 +806430,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -808685,6 +806948,24 @@
0,
0,
6,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -808834,6 +807115,22 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -808842,6 +807139,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -808863,6 +807168,14 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -809063,31 +807376,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -809295,30 +807583,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -809327,43 +807591,55 @@
0,
0,
0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "txmonster-mud-day-demo",
- "sourceId": "3GSMUH",
- "title": "TxMonster - MUD Day Demo",
- "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications\r\n\r\nUsing MUD Dev to build \"Eat Sleep & Survive\" TxMonster on RedStone Chain",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Lightning Talk",
+ "id": "understanding-eip-7002-and-eip-6110",
+ "sourceId": "KPD8HB",
+ "title": "Understanding EIP-7002 and EIP-6110",
+ "description": "The first part will be an overview of EIP-7002, explaining how it works, why adding this extra option to exit validators is important, and addressing some of the UX challenges of this approach. The second part will be a technical overview of EIP-6110, explaining the UX improvements for validators depositing on the beacon chain, the removal of pre-merge technical debt as well as a quick look at the EIP implementation in Teku.",
+ "track": "Core Protocol",
+ "type": "Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
+ "tags": [
+ "Staking"
+ ],
"keywords": [
- "N/A"
+ "EIP",
+ "validator",
+ "staking"
],
- "tags": [],
+ "duration": 1495,
"language": "en",
- "speakers": [
- "buidltxgames"
- ],
+ "sources_swarmHash": "5e5addf0da8b7cde13a38f9d5bf27a477cb4b61980091c63038ec72253663a34",
+ "sources_youtubeId": "EyDChjFQEkQ",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330efd3a168eb535f36fc6.vtt",
+ "transcript_text": " It is bright. Okay, so, yeah, I'm Lucas and I've got Stefan here with me. Our talk was originally designed to be two talks, but do some scheduling things. We had to merge them together. So, well, we'll do our best to make sure we go through the content and everyone understands everything. So, yeah, I'll start with my part and then we're going to have Stefan. Thank you, Stefan. Okay. So we're going to start with EIP7002, execution layer triggerable withdrawals. Before it was named execution layer triggerable exits, but there are some updates that we renamed it ZIP. Before talking about ZIP, I want to go through a little bit of a context here. I'm assuming that everyone is aware that in Ethereum we have validators, and they are staking 32 ETH, and then they're performing the duties like voting for new blocks with attestations, proposing new blocks, and things like that. And well, when you're creating a validator, maybe everyone knows that, but we have two sets of credentials. You have your validator key, which is associated with your validator public key, which is used for signing your blocks, signing your attestations and everything. And you have your withdrawal key, which is kind of represents the ownership of the staked amount of ETH. Another concept is solid staking versus delegated staking. So this is kind of a different thing. Like staking is staking. But I think solid staking will be kind of the most basic thing when you think about staking. You know, you have a laptop. You create a validator, you have the validator key, you have your withdrawal key, so you own kind of everything. And when it comes to delegate staking, there is like a bunch of different arrangements. You have custodial, noncustodial. But for this exercise, let's just assume that you own the withdrawal key. Someone else owns the validator key because they're running your node for you. But they do need the key because they're going to be signing the attestations and everything. So they need the key. So that's just to do with that. Okay. Another thing before we jump into the EIP, I want to touch on voluntary exits. So voluntary exits since phase zero has been pretty much the same. If you want to exit the validator, you don't want to stake anymore. You will send a signed voluntary exit message, but that message is signed with your validator key. So you sign that message, broadcast it through, send it through the beacon API. It's going to be propagated in the network, eventually included in a block, and after some time your validator joins the exit queue. Pretty straightforward. However, as you can see in the diagram here, if you don't have the validator key, you're kind of in trouble because you don't really have a way of exiting your validator. You need to kind of ring your operator, hey, could you please exit my validator for me? Well, if they are nice people, they will do it for you. But, you know, it's kind of like a grief attack vector because technically the node operator can, like, not really do their best job when doing the decisions and everything. And they have ways of, like, slowly chipping away your stake, which is not great. There are ways around this. Some of the operators will give you a pre-signed exit message when you join the system. So you keep that message safe whenever you want to exit. You already have the signed message and then you can exit. This is a workaround because there are a lot of complications with this. There's a lot of, you know, you need to keep that message safe. You don't you're not 100% sure if that message is going to work. And they have to have all the infrastructure around managing that message and everything. So it's, yeah, it's kind of a hack. Well, back to the problem that we're talking about. You can only exit your validator today with your validator key. Right? And the solution is easy. Just allow both the validator key and the withdrawal key to exit the validator. Yep, it's pretty straightforward. Unfortunately, implementing it, it's not that easy. And that's pretty much the context on how we get to EIP 7002. So, why it's not easy? It's important to remember that when it comes to the consensus layer and the execution layer, the consensus layer doesn't have a complete view of what happens on the execution layer. So it's got a limited amount of information that comes through that side. I think a good example of this is if you think about deposit processing. Stefan is going to be talking a little bit about it later. It's a complicated mess. It's a whole system, keeps updating and fetching information. It's not that easy. So what we really need is we need a mechanism to create a message on the execution layer, send that message all the way to the consensus layer, but that message has to be authenticated with an account on the execution layer side, but at the same time, all the authorization happens on the consensus layer side, because the consensus layer is the one that knows who is the validator, what is the withdrawal credential associated with that validator, what is the balance, and all this kind of stuff. So that's kind of the thing that we're trying to solve here. And that's pretty much the idea with withdrawal requests. So it's a request that comes from the EL, goes to the CL, and it's got pretty much three pieces of information. One is the source address, which is supposed to be the address that you have set as withdrawal credential on your validator. The public key, which is basically what is the validator you are sending this request to. And the amount, which is an interesting one. So before we didn't have the amount. So the amount was introduced because after EIP-7251, if you guys were here to listen to post-talk on MaxEB, now it's possible for validators to have more than 32 ETH balance, right? So technically you can have a validator with like 1,000 ETH or something staked. So we basically split the withdrawal into two different types of withdrawal. You can do a full withdrawal, which means I want to withdraw every single way that I have staked, which basically translates into an exit. Or I want to do a partial withdrawal, which means, well, you know, I have 100 ETH. I want 50 back because I want to buy a new car or something. So you do like a partial withdrawal. You get it back into your account, and then you can use the money. And we use the amount field for that. So an amount equals zero means a full withdrawal, which can be a bit weird to think about. And an amount greater than zero is like a partial withdrawal. I just want to withdraw part of my stake. Hopefully everything makes sense until now. And on this diagram, I'm trying to capture how things have changed compared to the previous diagram. So the way that we're creating this mechanism is basically now we're going to introduce this withdrawal request smart contract on the execution layer side. And that contract has pretty much two functions. So the first one is a function that the user is going to call to basically create a request. So when the user wants to create a request, I'm going to send a transaction, signing it with my withdrawal key, not the validator key, and the control is going to look at it like, oh, okay, that's cool. Someone's creating a withdrawal request. It's going to set that address as the source address on the request. And I'm going to be on this request here. We pass two pieces of information, the validator public key and the amount. Eventually, the execution client is going to call the contract and read the information for it, read the request that are on the queue. The queue is on the contract state. And send it over to the Beacon node through engine API, and I'm not going to go into a lot of details of that because, again, not a lot of time, but basically whenever it's time to create a block, the Beacon node is going to receive those requests from the EL, some verification happens and everything, and then the authorization part happens on the consensus side. It's going to look at the request, make sure that the source address, so the account that is sending this transaction here matches the validator on the consensus side and some other rules, you know, make sure that you're creating a request for the right validator and everything. Cool. So hopefully this makes a bit more sense. One interesting thing to note here, and that was actually probably half of my original talk is that when you look at this kind of orange area here, you can see that this mechanism for sending requests from EL to CL can be quite useful for a bunch of different things. And yep, we did notice that. And that's why we have EIP 7685, which introduced this concept of general purpose execution layer requests. So now we already have all this mechanism for creating different types of requests. For the next fork vector, we already have three types of requests. We have withdrawals, the ones we were just talking about. We have deposits, the one that Stefan is going to be talking about. And if you were here for the previous talk, consolidations, it also happens through an execution layer request. So that was kind of the most interesting part of this system. So take a look into that because it's pretty cool. Before I finish, I just want to go through a few caveats because there's no free lunch. There's always something that you need to give away. So the problem with request and kind of the execution request in general is that creating a successful transaction on the EL side, like creating a request, doesn't guarantee that that request is going to be successfully processed on the consensus layer side. I know it sounds a bit weird, so the user experience is a bit clunky. You kind of need to look at the consensus side, make sure that everything works out, create the request, and just kind of hope that nothing's going to change in this in-between. Hopefully it's not going to be too bad, but it can happen. And another interesting thing is if you currently have a validator and your validator has a contract address set as withdraw credentials, well, things are going to be a bit more complicated. For those of you who are familiar with the EVM, the contract that is creating the request is not looking at the transaction sender for authentication. It's looking for the message caller. So that means that if you are interacting with the request contract using a smart contract, the smart contract address is going to be the one that's going to end up on the source address. So for this whole thing to work, your validator with your credentials has to be the contract address, not the account that is sending the transaction. So again, I'm sorry for you if you're in this situation. Hopefully if you have an upgradable smart contract, you can get away with it. You can use delegate calls and do some very smart stuff to make it work. That's not my expertise. I'm not going to talk too much about it. But there is a way for you. Just keep that in mind when you are looking into this. One important thing is that this does not replace voluntary exits. Voluntary exits are still the easiest way to exit your validator. If you have the validator key, you sign the message. It's going to be broadcast to the network. It doesn't cost you gas or anything. There's no transactions involved. So, yeah, keep doing that if you can. But this is basically like a way of kind of filling that gap that we have on those scenarios where you don't have your validator key. And quickly before I run out of time, I just want to mention that withdrawal requests are different from withdrawals in the sense that if you guys remember Capella, that's when we introduced withdrawals. A withdrawal request can eventually generate a withdrawal when you're doing a partial withdrawal. But they're not the same thing. Just because you have the terminology and things like that. Okay. That was a lot. Hopefully enough for people to understand. I'll leave it here and then I'll hand over to Stefan for his part. Thank you. Oh, thank you. How does that work? Yeah, Next slide. . Okay. Hello. So I'm going to talk about EIP6110, which is supply validator deposits on chain. And you may wonder what this EIP is about because validator deposits are already on chain. But the keyword here is supply. So essentially, this EIP changes how the deposits made to the deposit contract, which sits on the execution layer, how these deposits are supplied to the consents layer, where either a new validator is initialized or an existing validator balance is topped up. So I'm going to start by explaining briefly how the current deposit processing works. And then I'll go over the depositing processing after this EIP, which will be part of the next fork. Yeah. So current deposit processing, basically a user submits a transaction containing deposit data to the deposit contract, which is essentially 32 if. And users usually do that via the staking launchpad. And then there is this eight hour delay where the consensus layer has to consider the state of the deposit contract and this has been designed to be 2048 blocks when with proof-of-work blocks which are which were around 14 seconds. And this was done to ensure that if there are any issues with if one, then essentially that wouldn't impact the beacon chain. And eight hours was just it gives about enough wiggle room to ensure that any issues are fixed. And then there is a voting which is a 64 epochs. And it's kind of, this is like off protocol consensus mechanism. It was designed before the merge. And basically it ensures that validators agree on the state, on the same view of the deposit contract, which sits in the EL. And before the merge, basically the EL is driven by proof of work. So there was no real connection between the execution layer and the consensus layer. And then this voting, basically, it finishes when at least half number of the votes are the same. And after that, proposers include those deposits alongside the block. And then all nodes can verify these blocks. And then a valid deposit basically either creates a new validator or it tops out with the balance of an existing validator. And this is a diagram of the current process. So you can see this user. He basically does a deposit transaction, uses the Stenky launch pad, and then the important part here is basically you can see on the right the beacon node, and it has this chunky EF1 module which constantly pulls the EL via the JSON RPC API. And it does that 2048 blocks constantly. In order to build the Merkle tree, which then can be used to produce proofs, which are included alongside deposits. And this is the current process, which is still Ethereum works like that, even though we have already migrated to proof of stake. We still use this JSON RPC. And the way this, the EAP6110 works is it simplifies a lot. Basically the same deposit transaction is made, but then the deposits come directly from the EL via the engine API, and they're included in blocks, and then they're processed on finalization of the chain, which is currently around 13 minutes. And then the same flow, again, the same thing, a valid deposit will either create new validator or top up an existing validator. And the diagram now looks like this, which is pretty much what Lucas showed. You basically have the execution requests. And now you get the deposit request over the Engine API. So whenever a proposer proposes a block, they get the deposit requests. And basically, this whole EF1 module, which was quite quite chunky now it's no longer part of the beacon node. So this is the diagram. And to quickly summarize the advantages of the EIP, basically there is nowadays a delay of around 11.4 hours before your validator is added to the activation queue. And this is basically the follow distance, these 2048 blocks, which is around eight hours. And then there's this voting of around 32 epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs. And another advantage is the increased security because we no longer rely on this off-protocol mechanism. Now we just inherit the security of the chain. And also there is another benefit because currently we have this deposit contract snapshots which basically are a Merkle tree up to a certain point in time. And we no longer need this because we no longer need to provide proofs because we are just getting the deposits from the engine API. And one other benefit is that we no longer rely on the JSON RPC API. We only rely on the engine API. And it's also we just no longer need that very legacy and brittle part of the CL client's code, which is always good to delete stuff. And one more slide I wanted to show, I wanted to quickly show that this EIP is actually not, it's actually simple to implement. So if you're interested, you can go over this link and see how we implement it. We generally try to do small PRs, so it's just eight PRs, but it's not big changes. So if you ever want to check how an EAP is implemented, actually, this is a good one to go over because it's quite simple. Yeah, and that's it, pretty much. Thank you pretty much. Thank you, thank you. We're going to get to some questions now. And again, if you're new to seeing a talk today, scan the QR code, add your question, and you can vote. If there's one that's already there and you would like to see it answered, just to make sure it gets answered and pushed to the top of the queue. Thank you, thank you. So we will start with why a valid request from the execution layer would be rejected on the consensus layer? I can probably take that one. It's hard to go through all the different reasons why. I think the best way of thinking about it is that I like to separate that the EL is doing the authentication side of the request and the CL is doing the authorization side of the request. So I think the easiest example that I can think of, for example, for withdrawal requests, let's say that you create a request for someone else's validator. So the transaction is going to be successful. The request is going to be added to the contract. But when the CL receives that request, it's going to try to match the source address with the validator with your credentials. It's going to say, well, you don't really own that. You can't really do that. So that's one of the reasons. Yeah, there are other more specific rules that can, but I think that's probably the easiest way to think about it. The EL doesn't really know the business rules on the CL side in the same way that the EL can't really validate beforehand that that's the right validator. So that's kind of part of the reason, hopefully. Yeah, that's it. Thank you. part of the reason hopefully yeah that's it thank you and it looks like we have another one for you right again so why do you think contract address as a withdrawal credential is a caveat um it's it's more like it's a more complicated thing because um there are two problems with this one is that the currently the validator withdrawal credentials cannot be updated. So once you... I didn't really touch on the whole BLS credential side of things, which is something that already was there before. But the way that it works right now, once you set your validator withdrawal credentials to one address, you can never change that address. So a few problems happen here. The first one is, as I mentioned, if you have your validator credentials set to a contract address that is not upgradable, you're never going to be able to update that code to call the request contract. So you're already kind of locked out from this mechanism straight away. If you have an upgradable contract, you can write some code to kind of get around it. So it's more like a caveat in terms of something that people need to get their heads around and make sure that they consider when they're implementing. Because I think the natural thing to think is, well, I'm going to sign the transaction with this credential, with this account, sorry, key, and that's the one that's going to show up on the request. But that's why it's kind of a caveat. Thank you. All right. Now for you. If EIP-6110 makes ETH1 vote legacy, do we have to carry all ETH1 voting fields and logics in consensus layer, even in post-Electra? Yeah, sure. So there is a little bit of transition period when post-Electra to transition to the new way, because we still have to process deposits by the old way for some time. But after that is done, we can pretty much remove all of this legacy code in next releases after the fork. Thank you. Is there a proof generation process to withdraw, similar to performing Eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals process, but there's no proof generation on this withdrawal. Hopefully, if I understand the question, there's no proof generation. What if a deposited request failed? Will users' ETH be refunded? So, when you deposit ETH to the smart contract, there is technically no way a deposit request fails. So if the deposit request fails, that means that there is like a consensus failure, which, yeah, it wouldn't be refunded, but it's a big issue. All right, I think we have time for one, maybe two more. How resilient is the engine API comparing to JSON RPC API? Yeah, so the engine API basically drives the execution. The consensus layer client drives the execution layer client via the engine API. So it is very resilient. The JSON RPC API can... It's not... It's still very reliable, but it is not critical. So there could be some implementations in some clients which are less reliable than the engine API, which is very critical. Awesome. And we have just about five seconds left, so probably not enough time to get to the next question, but if you'd like to come up to the speakers and ask them questions later, they'll be sticking around for a little bit. So thank you very much. Let's have a big one.",
"eventId": "devcon-7",
- "slot_start": 1731558000000,
- "slot_end": 1731558300000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/10U4OcgkMv_HGXoZzHe-sIP9e08AcMp-G142YBiu1DUM"
+ "slot_start": 1731396600000,
+ "slot_end": 1731398400000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/13NjraDw6-VLGwVGpYUmZprFK68Rq7uVHZ7yVIgSx7Q0",
+ "resources_slides": null,
+ "speakers": [
+ "lucas-saldanha",
+ "stefan-bratanov"
+ ]
},
"vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -809372,7 +807648,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -810046,6 +808321,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -810237,11 +808513,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -810695,32 +808967,44 @@
},
{
"session": {
- "id": "ultimate-dominion-mud-day-demo",
- "sourceId": "GPQVMW",
- "title": "Ultimate Dominion - MUD Day Demo",
- "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nUltimate Dominion is a fully onchain text-based RPG. Explore the world, defeat monsters, collect, buy, and sell items.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Lightning Talk",
- "expertise": "Beginner",
+ "id": "unified-ethereum-vs-l2-ecosystem-competition-can-we-have-both",
+ "sourceId": "HZCDFP",
+ "title": "“Unified Ethereum” vs “L2 Ecosystem Competition”: Can we have both?",
+ "description": "This panel will dig into the delicate balance of Ethereum's rollup-centric future. We'll talk about the \"frenemy\" dynamic between competing L2 ecosystems, and how this can lead to a fragmented user experience. We'll strategize on ways to maintain diversity while making interoperability easy for users—including a discussion on the pros/cons of supporting standards like ERC-7683. Can we get the best of both worlds: the innovation and diversity of many L2s, with the UX of a unified Ethereum?",
+ "track": "Layer 2",
+ "type": "Panel",
+ "expertise": "Intermediate",
"audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [],
+ "keywords": [
+ "ERC-7683",
+ "Interoperability",
+ "Unified-Ethereum"
+ ],
"tags": [
- "Gaming",
- "Autonomous World",
- "Autonomous World",
- "Gaming"
+ "Cross-L2",
+ "UI/UX",
+ "Intents",
+ "ethereum",
+ "unified",
+ "Cross-L2",
+ "Intents",
+ "UI/UX"
],
"language": "en",
"speakers": [
- "ritz-raspa"
+ "hart-lambur",
+ "ben-jones",
+ "vitalik-buterin",
+ "steven-goldfeder",
+ "jesse-pollak"
],
"eventId": "devcon-7",
- "slot_start": 1731558300000,
- "slot_end": 1731558600000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/13Uil3sm_cj9Qi6g5Yd7Wn1eUVWbT6tRsAAUDqNmNTmU"
+ "slot_start": 1731479400000,
+ "slot_end": 1731483000000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1sjVmE9pcutiBwFVJbYVV2KdRqnNTg_wv6ZwyrExBY2Y"
},
"vector": [
0,
@@ -810730,11 +809014,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -810917,6 +809196,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -811160,6 +809440,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -811221,6 +809502,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -811409,15 +809691,11 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -811533,9 +809811,11 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -811585,8 +809865,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -811678,6 +809956,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -811784,6 +810063,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -812009,6 +810289,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -812036,9 +810317,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -812058,46 +810339,45 @@
},
{
"session": {
- "id": "unchained-index-a-purposefully-designed-schelling-point-a-native-web3-api",
- "sourceId": "VBUJML",
- "title": "Unchained Index: A Purposefully Designed Schelling Point: A native Web3 API",
- "description": "The Unchained Index smart contract, part of TrueBlocks, acts as a purposefully-designed Schelling Point, creating a decentralized, permissionless store for blockchain index data. In this talk, we generalize the Unchained Index to show it can serve as a repository for other datasets such as event signatures and address labels. We contend we can replace costly APIs with a robust, reproducible public good, enhancing data accessibility & decentralization.",
- "track": "Coordination",
+ "id": "universal-eccs-use-cases-for-the-p256-precompile-in-decentralized-internet-infrastructure",
+ "sourceId": "NX7U8B",
+ "title": "Universal ECCs: Use Cases for the P256 Precompile in Decentralized Internet Infrastructure",
+ "description": "## Summary\r\n\r\nThe session will highlight the history of adoption of P256 in Elliptic Curve Cryptography (ECC), its current applications in web security, authentication, and encryption, and explore future possibilities for its integration into Ethereum and ENS to enhance decentralized internet infrastructure.",
+ "track": "Core Protocol",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "none"
- ],
"tags": [
- "Coordination",
- "Decentralization",
- "Ethereum for Good",
- "Coordination",
- "Decentralization",
- "Ethereum for Good"
+ "ens",
+ "Accessibility",
+ "Public good",
+ "Use cases of cryptography"
],
- "language": "en",
- "speakers": [
- "thomas-jay-rush",
- "meriam-zandi"
+ "keywords": [
+ "ENS"
],
+ "duration": 522,
+ "language": "en",
+ "sources_swarmHash": "d137af18f4692a1194d1e3d606910f72833ec4282b51cac0a9b1a317238c2ef2",
+ "sources_youtubeId": "e_QBTQGMxPs",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67341e6c9dbb7a90e1685ea7.vtt",
+ "transcript_text": " Okay, for those who don't, you should definitely get one today. Meet me at the Enos booth and I'll help you out with that. And how many of you guys have more than one login across different platforms, like your bank accounts, social media, etc., etc. Yeah, I do too, pretty much everyone. So basically what I'm trying to do today is convince you that a single login is much more effective and much more useful than various ones, obviously, right? The problem is that for those of you that don't know, there might be a security concern with the P256 precompile. And I'm not going to get into the technical details of that today. I'm just going to try to plant a seed in your head and ask you to consider implementing this in the EVM. If you are a core dev, if you meet up at the ACD calls, please take this into consideration. So let's begin. So the problem is digifrenia. What is this? This is a term coined by Douglas Rushkoff. And essentially, it's the feeling of having your identity fragmented across different platforms. And this kind of leads to a lot of tension, like internal tension, a lot of anxiety, a lot of anger, depression. And, you know know this is a endemic to our terminally online generation right so we really want to find a way how to alleviate it and I'm personally not of the opinion that we should be taking over you know drugs or anything like that to do that there's a more simple solution, right? Again, when you have your identity fragmented across different platforms, it leads to serotonin and dopamine deficiencies, which leads to all these like really bad things. And you do really bad things once you feel really bad, right? So fragmented identities are bad for your health. And so what can we do about this, right? So what I'm proposing today is an idea, right? A hypothesis for a unified identity framework. And so what this means is to have more sovereignty, more control, and more self-empowerment over your identity online across different platforms. And I'm not just talking about Ethereum. I'm talking about the entire internet, right? And ENS serves as a bridge from Web3 to Web2, but there is a blocker, right? Before we get to that, just want to reiterate that having a unified identity across different platforms would lessen the tension that we are all experiencing today as a terminally online generation, right? So universal logins with ENS, right? For those of you who are familiar, you probably connect your wallet and have your ENS set up and you can receive and send payments with your ENS. It makes it super easy, delightful user experience. But I personally would love to, for example, log into my Chase account with an ENS name. I'd love to pay my bills with my ENS name. I'd love to apply to college with my ENS name. I'd love to do everything with my ENS name. And that's not possible today because the P256 precompile is not currently implemented in the EVM. And there was an EIP, EIP-7212, that was under consideration that eventually became a roll-up improvement proposal, and that's been implemented across different L2s. But essentially, the path of 1 billion is actually much easier than we are led to believe. It's actually already there. We just need to make this consideration of integrating the P256 precompile into the L1. Yeah, so that's pretty much it. Just a seed, something for you guys to think about for the rest of your day. Here are some prompts for the Q&A if you guys want to go ahead and ask. And yeah, that's my talk. Yeah. Thank you. Questions? It's time. We've got a question, first one. Thank you. Questions? Time. We've got a question. First one. Okay. Oh. I'll try. Okay. Okay. Hey, what's your name? Hey, my name is Lance. Hey, Lance. I'm building a project called Sarray, and we use P256 verification in our project twice, one for WebAuthn and one for TLS Notary. I love that. We end up spending 600k gas total on these transactions and I was wondering why hasn't P256 been a pre-compile since the beginning? I mean it makes sense. Yeah so that's a great question. So everyone here is familiar with Edward Snowden and I believe that he's disclosed that there's a potential backdoor risk. It's a pseudo-random curve, right? So the Ethereum L1, it's a Koblitz curve, so it's deterministically conceived, whereas the P256 is a pseudo-random curve. So there's this concern that there might be a backdoor that the NSA or some other agency might have an ability to take advantage of. So that has not yet been proven, and there is evidence towards it not being a conclusive thing. But I think a lot of people here, I don't mean to offend the audience, but I think you guys might be a little paranoid. Sorry. Yeah. Next question. Next question. Okay. You got two here. I tried. I tried. I tried. Hey, what's your name? Hey, my name's Brian. I'm just playing devil's advocate here. Why can't we get the rest of the world to adopt the K curve? Pardon? Why can't we get the rest of the world to adopt 256K1? Why can't we get the rest of the world to adopt the P256 curve? The K curve. Oh, okay okay like do it the other way around yes oh man so um essentially like every uh every enterprise business has adopted this uh nist approved curve and uh you know i mean i guess we can like if we all came together and just uh kind of created a proposal to do that, but I feel like that would be like an uphill battle, in my opinion. But I mean, feel free to argue against that. Last question. Guys, let's do this. Last question. Okay, I've got a question for you. Okay, sir. So I'm from Africa, Ghana. Before L2s, Ethereum was like no-go area for most of us. I'm paying $10 for just a gas fee. What's the future in terms of making it easy for early devs who doesn't have so much to pay on gas to be able to use this seamlessly. Do you mind asking a question another way? I mean, how, in terms of future, for emerging markets like Africa, for early devs who are not in your level to be able to easily play with this particular technology that you're just discussing here? Are you asking, like, what would be the advantages of having this crypto implemented for emerging markets? I think it's just a universal thing, right? So if we're able to log in to... What's your bank account in Ghana? What's the name of your bank account? Well, I hardly go to bank now. I use crypto. Exactly. Okay. So, for example, if you're able to log in with your E&S to your bank account, it might be more easy to access versus just using crypto. Awesome. Awesome. Thank you. I mean, guys, let's give a hands-up applause for Marcus. Thanks.",
"eventId": "devcon-7",
- "slot_start": 1731492000000,
- "slot_end": 1731492600000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/12qCfXtoD8E9oGVRdfTgU97VfTsXFeb1ceIy1bYwWAV0"
+ "slot_start": 1731467100000,
+ "slot_end": 1731467700000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1-xDtu6rJ4NegQFgMrkNcVtzLJVJkvrYD_L3OYcBdFQo",
+ "resources_slides": null,
+ "speakers": [
+ "estmcmxcieth"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -812778,21 +811058,6 @@
0,
0,
0,
- 6,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -812802,6 +811067,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -812889,6 +811155,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -812920,6 +811187,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -812945,7 +811213,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -812998,9 +811265,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -813397,6 +811661,18 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -813404,7 +811680,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -813418,6 +811693,15 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -813426,56 +811710,52 @@
},
{
"session": {
- "id": "understanding-eip-7002-and-eip-6110",
- "sourceId": "KPD8HB",
- "title": "Understanding EIP-7002 and EIP-6110",
- "description": "The first part will be an overview of EIP-7002, explaining how it works, why adding this extra option to exit validators is important, and addressing some of the UX challenges of this approach. The second part will be a technical overview of EIP-6110, explaining the UX improvements for validators depositing on the beacon chain, the removal of pre-merge technical debt as well as a quick look at the EIP implementation in Teku.",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "unlock-web2-data-with-tlsnotary-hands-on-workshop",
+ "sourceId": "VPMQGM",
+ "title": "Unlock Web2 Data with TLSNotary: Hands-On Workshop",
+ "description": "Join our hands-on workshop to master **TLSNotary**! Dive into multi-party-TLS and learn to prove and verify online data authenticity to a third-party verifier while ensuring privacy. We’ll start with small examples in Rust and build up to custom browser extensions in TypeScript to collect and verify private user data.\r\n\r\nBring your laptop, bring a friend, and learn together. Get ready to unlock and compose Web2 data in innovative ways.",
+ "track": "Applied Cryptography",
+ "type": "Workshop",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Staking"
- ],
"keywords": [
- "EIP",
- "validator",
- "staking"
+ "oracle"
+ ],
+ "tags": [
+ "Live Coding",
+ "Privacy",
+ "MPC",
+ "oracle",
+ "Live Coding",
+ "MPC",
+ "Privacy"
],
- "duration": 1495,
"language": "en",
- "sources_swarmHash": "5e5addf0da8b7cde13a38f9d5bf27a477cb4b61980091c63038ec72253663a34",
- "sources_youtubeId": "EyDChjFQEkQ",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330efd3a168eb535f36fc6.vtt",
- "transcript_text": " It is bright. Okay, so, yeah, I'm Lucas and I've got Stefan here with me. Our talk was originally designed to be two talks, but do some scheduling things. We had to merge them together. So, well, we'll do our best to make sure we go through the content and everyone understands everything. So, yeah, I'll start with my part and then we're going to have Stefan. Thank you, Stefan. Okay. So we're going to start with EIP7002, execution layer triggerable withdrawals. Before it was named execution layer triggerable exits, but there are some updates that we renamed it ZIP. Before talking about ZIP, I want to go through a little bit of a context here. I'm assuming that everyone is aware that in Ethereum we have validators, and they are staking 32 ETH, and then they're performing the duties like voting for new blocks with attestations, proposing new blocks, and things like that. And well, when you're creating a validator, maybe everyone knows that, but we have two sets of credentials. You have your validator key, which is associated with your validator public key, which is used for signing your blocks, signing your attestations and everything. And you have your withdrawal key, which is kind of represents the ownership of the staked amount of ETH. Another concept is solid staking versus delegated staking. So this is kind of a different thing. Like staking is staking. But I think solid staking will be kind of the most basic thing when you think about staking. You know, you have a laptop. You create a validator, you have the validator key, you have your withdrawal key, so you own kind of everything. And when it comes to delegate staking, there is like a bunch of different arrangements. You have custodial, noncustodial. But for this exercise, let's just assume that you own the withdrawal key. Someone else owns the validator key because they're running your node for you. But they do need the key because they're going to be signing the attestations and everything. So they need the key. So that's just to do with that. Okay. Another thing before we jump into the EIP, I want to touch on voluntary exits. So voluntary exits since phase zero has been pretty much the same. If you want to exit the validator, you don't want to stake anymore. You will send a signed voluntary exit message, but that message is signed with your validator key. So you sign that message, broadcast it through, send it through the beacon API. It's going to be propagated in the network, eventually included in a block, and after some time your validator joins the exit queue. Pretty straightforward. However, as you can see in the diagram here, if you don't have the validator key, you're kind of in trouble because you don't really have a way of exiting your validator. You need to kind of ring your operator, hey, could you please exit my validator for me? Well, if they are nice people, they will do it for you. But, you know, it's kind of like a grief attack vector because technically the node operator can, like, not really do their best job when doing the decisions and everything. And they have ways of, like, slowly chipping away your stake, which is not great. There are ways around this. Some of the operators will give you a pre-signed exit message when you join the system. So you keep that message safe whenever you want to exit. You already have the signed message and then you can exit. This is a workaround because there are a lot of complications with this. There's a lot of, you know, you need to keep that message safe. You don't you're not 100% sure if that message is going to work. And they have to have all the infrastructure around managing that message and everything. So it's, yeah, it's kind of a hack. Well, back to the problem that we're talking about. You can only exit your validator today with your validator key. Right? And the solution is easy. Just allow both the validator key and the withdrawal key to exit the validator. Yep, it's pretty straightforward. Unfortunately, implementing it, it's not that easy. And that's pretty much the context on how we get to EIP 7002. So, why it's not easy? It's important to remember that when it comes to the consensus layer and the execution layer, the consensus layer doesn't have a complete view of what happens on the execution layer. So it's got a limited amount of information that comes through that side. I think a good example of this is if you think about deposit processing. Stefan is going to be talking a little bit about it later. It's a complicated mess. It's a whole system, keeps updating and fetching information. It's not that easy. So what we really need is we need a mechanism to create a message on the execution layer, send that message all the way to the consensus layer, but that message has to be authenticated with an account on the execution layer side, but at the same time, all the authorization happens on the consensus layer side, because the consensus layer is the one that knows who is the validator, what is the withdrawal credential associated with that validator, what is the balance, and all this kind of stuff. So that's kind of the thing that we're trying to solve here. And that's pretty much the idea with withdrawal requests. So it's a request that comes from the EL, goes to the CL, and it's got pretty much three pieces of information. One is the source address, which is supposed to be the address that you have set as withdrawal credential on your validator. The public key, which is basically what is the validator you are sending this request to. And the amount, which is an interesting one. So before we didn't have the amount. So the amount was introduced because after EIP-7251, if you guys were here to listen to post-talk on MaxEB, now it's possible for validators to have more than 32 ETH balance, right? So technically you can have a validator with like 1,000 ETH or something staked. So we basically split the withdrawal into two different types of withdrawal. You can do a full withdrawal, which means I want to withdraw every single way that I have staked, which basically translates into an exit. Or I want to do a partial withdrawal, which means, well, you know, I have 100 ETH. I want 50 back because I want to buy a new car or something. So you do like a partial withdrawal. You get it back into your account, and then you can use the money. And we use the amount field for that. So an amount equals zero means a full withdrawal, which can be a bit weird to think about. And an amount greater than zero is like a partial withdrawal. I just want to withdraw part of my stake. Hopefully everything makes sense until now. And on this diagram, I'm trying to capture how things have changed compared to the previous diagram. So the way that we're creating this mechanism is basically now we're going to introduce this withdrawal request smart contract on the execution layer side. And that contract has pretty much two functions. So the first one is a function that the user is going to call to basically create a request. So when the user wants to create a request, I'm going to send a transaction, signing it with my withdrawal key, not the validator key, and the control is going to look at it like, oh, okay, that's cool. Someone's creating a withdrawal request. It's going to set that address as the source address on the request. And I'm going to be on this request here. We pass two pieces of information, the validator public key and the amount. Eventually, the execution client is going to call the contract and read the information for it, read the request that are on the queue. The queue is on the contract state. And send it over to the Beacon node through engine API, and I'm not going to go into a lot of details of that because, again, not a lot of time, but basically whenever it's time to create a block, the Beacon node is going to receive those requests from the EL, some verification happens and everything, and then the authorization part happens on the consensus side. It's going to look at the request, make sure that the source address, so the account that is sending this transaction here matches the validator on the consensus side and some other rules, you know, make sure that you're creating a request for the right validator and everything. Cool. So hopefully this makes a bit more sense. One interesting thing to note here, and that was actually probably half of my original talk is that when you look at this kind of orange area here, you can see that this mechanism for sending requests from EL to CL can be quite useful for a bunch of different things. And yep, we did notice that. And that's why we have EIP 7685, which introduced this concept of general purpose execution layer requests. So now we already have all this mechanism for creating different types of requests. For the next fork vector, we already have three types of requests. We have withdrawals, the ones we were just talking about. We have deposits, the one that Stefan is going to be talking about. And if you were here for the previous talk, consolidations, it also happens through an execution layer request. So that was kind of the most interesting part of this system. So take a look into that because it's pretty cool. Before I finish, I just want to go through a few caveats because there's no free lunch. There's always something that you need to give away. So the problem with request and kind of the execution request in general is that creating a successful transaction on the EL side, like creating a request, doesn't guarantee that that request is going to be successfully processed on the consensus layer side. I know it sounds a bit weird, so the user experience is a bit clunky. You kind of need to look at the consensus side, make sure that everything works out, create the request, and just kind of hope that nothing's going to change in this in-between. Hopefully it's not going to be too bad, but it can happen. And another interesting thing is if you currently have a validator and your validator has a contract address set as withdraw credentials, well, things are going to be a bit more complicated. For those of you who are familiar with the EVM, the contract that is creating the request is not looking at the transaction sender for authentication. It's looking for the message caller. So that means that if you are interacting with the request contract using a smart contract, the smart contract address is going to be the one that's going to end up on the source address. So for this whole thing to work, your validator with your credentials has to be the contract address, not the account that is sending the transaction. So again, I'm sorry for you if you're in this situation. Hopefully if you have an upgradable smart contract, you can get away with it. You can use delegate calls and do some very smart stuff to make it work. That's not my expertise. I'm not going to talk too much about it. But there is a way for you. Just keep that in mind when you are looking into this. One important thing is that this does not replace voluntary exits. Voluntary exits are still the easiest way to exit your validator. If you have the validator key, you sign the message. It's going to be broadcast to the network. It doesn't cost you gas or anything. There's no transactions involved. So, yeah, keep doing that if you can. But this is basically like a way of kind of filling that gap that we have on those scenarios where you don't have your validator key. And quickly before I run out of time, I just want to mention that withdrawal requests are different from withdrawals in the sense that if you guys remember Capella, that's when we introduced withdrawals. A withdrawal request can eventually generate a withdrawal when you're doing a partial withdrawal. But they're not the same thing. Just because you have the terminology and things like that. Okay. That was a lot. Hopefully enough for people to understand. I'll leave it here and then I'll hand over to Stefan for his part. Thank you. Oh, thank you. How does that work? Yeah, Next slide. . Okay. Hello. So I'm going to talk about EIP6110, which is supply validator deposits on chain. And you may wonder what this EIP is about because validator deposits are already on chain. But the keyword here is supply. So essentially, this EIP changes how the deposits made to the deposit contract, which sits on the execution layer, how these deposits are supplied to the consents layer, where either a new validator is initialized or an existing validator balance is topped up. So I'm going to start by explaining briefly how the current deposit processing works. And then I'll go over the depositing processing after this EIP, which will be part of the next fork. Yeah. So current deposit processing, basically a user submits a transaction containing deposit data to the deposit contract, which is essentially 32 if. And users usually do that via the staking launchpad. And then there is this eight hour delay where the consensus layer has to consider the state of the deposit contract and this has been designed to be 2048 blocks when with proof-of-work blocks which are which were around 14 seconds. And this was done to ensure that if there are any issues with if one, then essentially that wouldn't impact the beacon chain. And eight hours was just it gives about enough wiggle room to ensure that any issues are fixed. And then there is a voting which is a 64 epochs. And it's kind of, this is like off protocol consensus mechanism. It was designed before the merge. And basically it ensures that validators agree on the state, on the same view of the deposit contract, which sits in the EL. And before the merge, basically the EL is driven by proof of work. So there was no real connection between the execution layer and the consensus layer. And then this voting, basically, it finishes when at least half number of the votes are the same. And after that, proposers include those deposits alongside the block. And then all nodes can verify these blocks. And then a valid deposit basically either creates a new validator or it tops out with the balance of an existing validator. And this is a diagram of the current process. So you can see this user. He basically does a deposit transaction, uses the Stenky launch pad, and then the important part here is basically you can see on the right the beacon node, and it has this chunky EF1 module which constantly pulls the EL via the JSON RPC API. And it does that 2048 blocks constantly. In order to build the Merkle tree, which then can be used to produce proofs, which are included alongside deposits. And this is the current process, which is still Ethereum works like that, even though we have already migrated to proof of stake. We still use this JSON RPC. And the way this, the EAP6110 works is it simplifies a lot. Basically the same deposit transaction is made, but then the deposits come directly from the EL via the engine API, and they're included in blocks, and then they're processed on finalization of the chain, which is currently around 13 minutes. And then the same flow, again, the same thing, a valid deposit will either create new validator or top up an existing validator. And the diagram now looks like this, which is pretty much what Lucas showed. You basically have the execution requests. And now you get the deposit request over the Engine API. So whenever a proposer proposes a block, they get the deposit requests. And basically, this whole EF1 module, which was quite quite chunky now it's no longer part of the beacon node. So this is the diagram. And to quickly summarize the advantages of the EIP, basically there is nowadays a delay of around 11.4 hours before your validator is added to the activation queue. And this is basically the follow distance, these 2048 blocks, which is around eight hours. And then there's this voting of around 32 epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs, which is 33.4 hours. And now this is reduced to just around 13 minutes or two epochs. And another advantage is the increased security because we no longer rely on this off-protocol mechanism. Now we just inherit the security of the chain. And also there is another benefit because currently we have this deposit contract snapshots which basically are a Merkle tree up to a certain point in time. And we no longer need this because we no longer need to provide proofs because we are just getting the deposits from the engine API. And one other benefit is that we no longer rely on the JSON RPC API. We only rely on the engine API. And it's also we just no longer need that very legacy and brittle part of the CL client's code, which is always good to delete stuff. And one more slide I wanted to show, I wanted to quickly show that this EIP is actually not, it's actually simple to implement. So if you're interested, you can go over this link and see how we implement it. We generally try to do small PRs, so it's just eight PRs, but it's not big changes. So if you ever want to check how an EAP is implemented, actually, this is a good one to go over because it's quite simple. Yeah, and that's it, pretty much. Thank you pretty much. Thank you, thank you. We're going to get to some questions now. And again, if you're new to seeing a talk today, scan the QR code, add your question, and you can vote. If there's one that's already there and you would like to see it answered, just to make sure it gets answered and pushed to the top of the queue. Thank you, thank you. So we will start with why a valid request from the execution layer would be rejected on the consensus layer? I can probably take that one. It's hard to go through all the different reasons why. I think the best way of thinking about it is that I like to separate that the EL is doing the authentication side of the request and the CL is doing the authorization side of the request. So I think the easiest example that I can think of, for example, for withdrawal requests, let's say that you create a request for someone else's validator. So the transaction is going to be successful. The request is going to be added to the contract. But when the CL receives that request, it's going to try to match the source address with the validator with your credentials. It's going to say, well, you don't really own that. You can't really do that. So that's one of the reasons. Yeah, there are other more specific rules that can, but I think that's probably the easiest way to think about it. The EL doesn't really know the business rules on the CL side in the same way that the EL can't really validate beforehand that that's the right validator. So that's kind of part of the reason, hopefully. Yeah, that's it. Thank you. part of the reason hopefully yeah that's it thank you and it looks like we have another one for you right again so why do you think contract address as a withdrawal credential is a caveat um it's it's more like it's a more complicated thing because um there are two problems with this one is that the currently the validator withdrawal credentials cannot be updated. So once you... I didn't really touch on the whole BLS credential side of things, which is something that already was there before. But the way that it works right now, once you set your validator withdrawal credentials to one address, you can never change that address. So a few problems happen here. The first one is, as I mentioned, if you have your validator credentials set to a contract address that is not upgradable, you're never going to be able to update that code to call the request contract. So you're already kind of locked out from this mechanism straight away. If you have an upgradable contract, you can write some code to kind of get around it. So it's more like a caveat in terms of something that people need to get their heads around and make sure that they consider when they're implementing. Because I think the natural thing to think is, well, I'm going to sign the transaction with this credential, with this account, sorry, key, and that's the one that's going to show up on the request. But that's why it's kind of a caveat. Thank you. All right. Now for you. If EIP-6110 makes ETH1 vote legacy, do we have to carry all ETH1 voting fields and logics in consensus layer, even in post-Electra? Yeah, sure. So there is a little bit of transition period when post-Electra to transition to the new way, because we still have to process deposits by the old way for some time. But after that is done, we can pretty much remove all of this legacy code in next releases after the fork. Thank you. Is there a proof generation process to withdraw, similar to performing Eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals? Unfortunately, I'm not familiar with eigenlayer withdrawals process, but there's no proof generation on this withdrawal. Hopefully, if I understand the question, there's no proof generation. What if a deposited request failed? Will users' ETH be refunded? So, when you deposit ETH to the smart contract, there is technically no way a deposit request fails. So if the deposit request fails, that means that there is like a consensus failure, which, yeah, it wouldn't be refunded, but it's a big issue. All right, I think we have time for one, maybe two more. How resilient is the engine API comparing to JSON RPC API? Yeah, so the engine API basically drives the execution. The consensus layer client drives the execution layer client via the engine API. So it is very resilient. The JSON RPC API can... It's not... It's still very reliable, but it is not critical. So there could be some implementations in some clients which are less reliable than the engine API, which is very critical. Awesome. And we have just about five seconds left, so probably not enough time to get to the next question, but if you'd like to come up to the speakers and ask them questions later, they'll be sticking around for a little bit. So thank you very much. Let's have a big one.",
- "eventId": "devcon-7",
- "slot_start": 1731396600000,
- "slot_end": 1731398400000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/13NjraDw6-VLGwVGpYUmZprFK68Rq7uVHZ7yVIgSx7Q0",
- "resources_slides": null,
"speakers": [
- "lucas-saldanha",
- "stefan-bratanov"
- ]
+ "hendrik-eeckhaut",
+ "sinu",
+ "tsukino"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731577200000,
+ "slot_end": 1731582600000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/18dMKK1NHUfq3W_cP2sm0ttim6fH4ZLV0KlzLOZdAiZ0"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -814136,6 +812416,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -814302,6 +812583,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -814327,6 +812609,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -814346,14 +812630,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -814653,6 +812929,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -814782,9 +813059,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
0,
0,
@@ -814800,44 +813077,33 @@
},
{
"session": {
- "id": "unified-ethereum-vs-l2-ecosystem-competition-can-we-have-both",
- "sourceId": "HZCDFP",
- "title": "“Unified Ethereum” vs “L2 Ecosystem Competition”: Can we have both?",
- "description": "This panel will dig into the delicate balance of Ethereum's rollup-centric future. We'll talk about the \"frenemy\" dynamic between competing L2 ecosystems, and how this can lead to a fragmented user experience. We'll strategize on ways to maintain diversity while making interoperability easy for users—including a discussion on the pros/cons of supporting standards like ERC-7683. Can we get the best of both worlds: the innovation and diversity of many L2s, with the UX of a unified Ethereum?",
+ "id": "unlocking-new-possibilities-with-stateless-architecture-in-layer-2",
+ "sourceId": "NGZBJL",
+ "title": "Unlocking New Possibilities with Stateless Architecture in Layer 2",
+ "description": "Explore the potential of stateless architecture in Layer 2 solutions. As Layer 2 technologies evolve, we will discuss the fundamental trade-offs and present how combining client-side Zero-Knowledge Proofs (ZKPs) with stateless architecture enhances efficiency. This session will highlight innovative possibilities not yet widely discussed in the Ethereum community, showing how this approach can revolutionize scalability, security, and privacy.",
"track": "Layer 2",
- "type": "Panel",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Product",
+ "audience": "Developper",
"featured": false,
"doNotRecord": false,
"keywords": [
- "ERC-7683",
- "Interoperability",
- "Unified-Ethereum"
+ "Privacy",
+ "Scalability",
+ "Statelessness"
],
"tags": [
- "Cross-L2",
- "UI/UX",
- "Intents",
- "ethereum",
- "unified",
- "Cross-L2",
- "Intents",
- "UI/UX"
+ "statelessness"
],
"language": "en",
"speakers": [
- "hart-lambur",
- "ben-jones",
- "vitalik-buterin",
- "steven-goldfeder",
- "jesse-pollak"
+ "leona-hioki"
],
"eventId": "devcon-7",
- "slot_start": 1731479400000,
- "slot_end": 1731483000000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1sjVmE9pcutiBwFVJbYVV2KdRqnNTg_wv6ZwyrExBY2Y"
+ "slot_start": 1731495600000,
+ "slot_end": 1731497400000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1CkoCHWyFJ_4IDI_puC1cfrAXBQJADtCY7bYExgXn3xQ"
},
"vector": [
0,
@@ -815030,7 +813296,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -815274,7 +813539,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -815341,7 +813605,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -815531,7 +813794,10 @@
0,
0,
0,
- 6,
+ 0,
+ 0,
+ 0,
+ 0,
6,
0,
0,
@@ -815647,11 +813913,9 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -815792,7 +814056,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -815900,7 +814163,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -816115,6 +814377,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -816127,7 +814391,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -816161,11 +814424,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -816175,52 +814438,48 @@
},
{
"session": {
- "id": "universal-eccs-use-cases-for-the-p256-precompile-in-decentralized-internet-infrastructure",
- "sourceId": "NX7U8B",
- "title": "Universal ECCs: Use Cases for the P256 Precompile in Decentralized Internet Infrastructure",
- "description": "## Summary\r\n\r\nThe session will highlight the history of adoption of P256 in Elliptic Curve Cryptography (ECC), its current applications in web security, authentication, and encryption, and explore future possibilities for its integration into Ethereum and ENS to enhance decentralized internet infrastructure.",
- "track": "Core Protocol",
+ "id": "unlocking-the-future-onboarding-the-fixed-income-market-to-ethereumchallenges-and-opportunities",
+ "sourceId": "N3JJFU",
+ "title": "Unlocking the Future: Onboarding the Fixed Income Market to Ethereum—Challenges and Opportunities",
+ "description": "Discover how Ethereum can revolutionize the world’s largest market: fixed income. This talk will explore strategies for onboarding fixed income markets onchain by collaborating with regulators, adopting progressive compliance, and streamlining UI/UX. We'll also discuss how to tackle challenges such as chain navigation, liquidity fragmentation, and fiat-to-crypto onboarding to drive the next wave of mass adoption.",
+ "track": "Real World Ethereum",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "tags": [
- "ens",
- "Accessibility",
- "Public good",
- "Use cases of cryptography"
- ],
"keywords": [
- "ENS"
+ "DeFi"
+ ],
+ "tags": [
+ "Regulation",
+ "UI/UX",
+ "Account Abstraction",
+ "Economics",
+ "defi",
+ "Account Abstraction",
+ "Economics",
+ "Regulation",
+ "UI/UX"
],
- "duration": 522,
"language": "en",
- "sources_swarmHash": "d137af18f4692a1194d1e3d606910f72833ec4282b51cac0a9b1a317238c2ef2",
- "sources_youtubeId": "e_QBTQGMxPs",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67341e6c9dbb7a90e1685ea7.vtt",
- "transcript_text": " Okay, for those who don't, you should definitely get one today. Meet me at the Enos booth and I'll help you out with that. And how many of you guys have more than one login across different platforms, like your bank accounts, social media, etc., etc. Yeah, I do too, pretty much everyone. So basically what I'm trying to do today is convince you that a single login is much more effective and much more useful than various ones, obviously, right? The problem is that for those of you that don't know, there might be a security concern with the P256 precompile. And I'm not going to get into the technical details of that today. I'm just going to try to plant a seed in your head and ask you to consider implementing this in the EVM. If you are a core dev, if you meet up at the ACD calls, please take this into consideration. So let's begin. So the problem is digifrenia. What is this? This is a term coined by Douglas Rushkoff. And essentially, it's the feeling of having your identity fragmented across different platforms. And this kind of leads to a lot of tension, like internal tension, a lot of anxiety, a lot of anger, depression. And, you know know this is a endemic to our terminally online generation right so we really want to find a way how to alleviate it and I'm personally not of the opinion that we should be taking over you know drugs or anything like that to do that there's a more simple solution, right? Again, when you have your identity fragmented across different platforms, it leads to serotonin and dopamine deficiencies, which leads to all these like really bad things. And you do really bad things once you feel really bad, right? So fragmented identities are bad for your health. And so what can we do about this, right? So what I'm proposing today is an idea, right? A hypothesis for a unified identity framework. And so what this means is to have more sovereignty, more control, and more self-empowerment over your identity online across different platforms. And I'm not just talking about Ethereum. I'm talking about the entire internet, right? And ENS serves as a bridge from Web3 to Web2, but there is a blocker, right? Before we get to that, just want to reiterate that having a unified identity across different platforms would lessen the tension that we are all experiencing today as a terminally online generation, right? So universal logins with ENS, right? For those of you who are familiar, you probably connect your wallet and have your ENS set up and you can receive and send payments with your ENS. It makes it super easy, delightful user experience. But I personally would love to, for example, log into my Chase account with an ENS name. I'd love to pay my bills with my ENS name. I'd love to apply to college with my ENS name. I'd love to do everything with my ENS name. And that's not possible today because the P256 precompile is not currently implemented in the EVM. And there was an EIP, EIP-7212, that was under consideration that eventually became a roll-up improvement proposal, and that's been implemented across different L2s. But essentially, the path of 1 billion is actually much easier than we are led to believe. It's actually already there. We just need to make this consideration of integrating the P256 precompile into the L1. Yeah, so that's pretty much it. Just a seed, something for you guys to think about for the rest of your day. Here are some prompts for the Q&A if you guys want to go ahead and ask. And yeah, that's my talk. Yeah. Thank you. Questions? It's time. We've got a question, first one. Thank you. Questions? Time. We've got a question. First one. Okay. Oh. I'll try. Okay. Okay. Hey, what's your name? Hey, my name is Lance. Hey, Lance. I'm building a project called Sarray, and we use P256 verification in our project twice, one for WebAuthn and one for TLS Notary. I love that. We end up spending 600k gas total on these transactions and I was wondering why hasn't P256 been a pre-compile since the beginning? I mean it makes sense. Yeah so that's a great question. So everyone here is familiar with Edward Snowden and I believe that he's disclosed that there's a potential backdoor risk. It's a pseudo-random curve, right? So the Ethereum L1, it's a Koblitz curve, so it's deterministically conceived, whereas the P256 is a pseudo-random curve. So there's this concern that there might be a backdoor that the NSA or some other agency might have an ability to take advantage of. So that has not yet been proven, and there is evidence towards it not being a conclusive thing. But I think a lot of people here, I don't mean to offend the audience, but I think you guys might be a little paranoid. Sorry. Yeah. Next question. Next question. Okay. You got two here. I tried. I tried. I tried. Hey, what's your name? Hey, my name's Brian. I'm just playing devil's advocate here. Why can't we get the rest of the world to adopt the K curve? Pardon? Why can't we get the rest of the world to adopt 256K1? Why can't we get the rest of the world to adopt the P256 curve? The K curve. Oh, okay okay like do it the other way around yes oh man so um essentially like every uh every enterprise business has adopted this uh nist approved curve and uh you know i mean i guess we can like if we all came together and just uh kind of created a proposal to do that, but I feel like that would be like an uphill battle, in my opinion. But I mean, feel free to argue against that. Last question. Guys, let's do this. Last question. Okay, I've got a question for you. Okay, sir. So I'm from Africa, Ghana. Before L2s, Ethereum was like no-go area for most of us. I'm paying $10 for just a gas fee. What's the future in terms of making it easy for early devs who doesn't have so much to pay on gas to be able to use this seamlessly. Do you mind asking a question another way? I mean, how, in terms of future, for emerging markets like Africa, for early devs who are not in your level to be able to easily play with this particular technology that you're just discussing here? Are you asking, like, what would be the advantages of having this crypto implemented for emerging markets? I think it's just a universal thing, right? So if we're able to log in to... What's your bank account in Ghana? What's the name of your bank account? Well, I hardly go to bank now. I use crypto. Exactly. Okay. So, for example, if you're able to log in with your E&S to your bank account, it might be more easy to access versus just using crypto. Awesome. Awesome. Thank you. I mean, guys, let's give a hands-up applause for Marcus. Thanks.",
+ "speakers": [
+ "charles-st-louis"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731467100000,
- "slot_end": 1731467700000,
+ "slot_start": 1731580800000,
+ "slot_end": 1731581400000,
"slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1-xDtu6rJ4NegQFgMrkNcVtzLJVJkvrYD_L3OYcBdFQo",
- "resources_slides": null,
- "speakers": [
- "estmcmxcieth"
- ]
+ "resources_presentation": "https://docs.google.com/presentation/d/15KHZ8vK6GD9sf4oCsV5ZRJ5sKkMhq4oPgvFv-uAVHsY"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
+ 6,
0,
0,
0,
@@ -816994,16 +815253,11 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -817019,6 +815273,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -817074,7 +815329,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -817159,6 +815413,46 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -817491,53 +815785,15 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
2,
0,
0,
0,
0,
0,
+ 2,
+ 0,
+ 0,
0,
0,
0,
@@ -817549,52 +815805,54 @@
},
{
"session": {
- "id": "unlock-web2-data-with-tlsnotary-hands-on-workshop",
- "sourceId": "VPMQGM",
- "title": "Unlock Web2 Data with TLSNotary: Hands-On Workshop",
- "description": "Join our hands-on workshop to master **TLSNotary**! Dive into multi-party-TLS and learn to prove and verify online data authenticity to a third-party verifier while ensuring privacy. We’ll start with small examples in Rust and build up to custom browser extensions in TypeScript to collect and verify private user data.\r\n\r\nBring your laptop, bring a friend, and learn together. Get ready to unlock and compose Web2 data in innovative ways.",
- "track": "Applied Cryptography",
- "type": "Workshop",
+ "id": "unpacking-eof-applications-in-developer-infrastructure-and-tooling",
+ "sourceId": "87XNSS",
+ "title": "Unpacking EOF: Applications in Developer Infrastructure and Tooling",
+ "description": "In this talk, we will delve into the Ethereum Object Format (EOF), a pivotal component of the upcoming Pectra hard-fork, focusing on its profound implications for development infrastructure and tooling. EIP-7692 introduces a new execution environment and a structured format for executable code, bringing extensive changes to the Ethereum Virtual Machine (EVM).\r\n\r\nHow will it affect developers? What will make their lives harder and what easier?",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "oracle"
+ "EOF",
+ "EIP-7692",
+ "EVM"
],
"tags": [
- "Live Coding",
- "Privacy",
- "MPC",
- "oracle",
- "Live Coding",
- "MPC",
- "Privacy"
+ "Core Protocol",
+ "Developer Infrastructure",
+ "DevEx",
+ "EVM",
+ "Core Protocol",
+ "Developer Infrastructure",
+ "DevEx"
],
"language": "en",
"speakers": [
- "hendrik-eeckhaut",
- "sinu",
- "tsukino"
+ "nebojsa-urosevic",
+ "pavle-drobnjak"
],
"eventId": "devcon-7",
- "slot_start": 1731577200000,
- "slot_end": 1731582600000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/18dMKK1NHUfq3W_cP2sm0ttim6fH4ZLV0KlzLOZdAiZ0"
+ "slot_start": 1731562200000,
+ "slot_end": 1731562800000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1yIsFqKcISo1wBOpMh8bQqTwKa7ihE8HDSAKmoWXYRs8"
},
"vector": [
0,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -818259,7 +816517,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -818352,6 +816609,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -818362,6 +816620,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -818385,6 +816644,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -818425,10 +816685,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -818451,8 +816707,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -818543,6 +816797,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -818774,7 +817029,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -818901,9 +817155,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
0,
@@ -818919,38 +817173,41 @@
},
{
"session": {
- "id": "unlocking-new-possibilities-with-stateless-architecture-in-layer-2",
- "sourceId": "NGZBJL",
- "title": "Unlocking New Possibilities with Stateless Architecture in Layer 2",
- "description": "Explore the potential of stateless architecture in Layer 2 solutions. As Layer 2 technologies evolve, we will discuss the fundamental trade-offs and present how combining client-side Zero-Knowledge Proofs (ZKPs) with stateless architecture enhances efficiency. This session will highlight innovative possibilities not yet widely discussed in the Ethereum community, showing how this approach can revolutionize scalability, security, and privacy.",
- "track": "Layer 2",
- "type": "Talk",
+ "id": "updating-gas-cost-schedule-based-on-reproducible-benchmarks",
+ "sourceId": "TZVK7F",
+ "title": "Updating Gas Cost Schedule based on reproducible benchmarks",
+ "description": "Sponsored by the Ethereum Foundation, our project evaluates the real cost of executing OPCODEs and procompiles in EVMs across diverse clients. We present the up-to-date benchmarks, the new Gas Cost Schedule proposal, a do-it-yourself solution to reproduce measurements in your environment, and an automated way to generate new proposals for each hard fork.",
+ "track": "Core Protocol",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developper",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Privacy",
- "Scalability",
- "Statelessness"
+ "Gas Cost Schedule",
+ "EVM Internals",
+ "Client Diversity",
+ "Node Infrastructure"
],
"tags": [
- "statelessness"
+ "Gas",
+ "Decentralization",
+ "infrastructure",
+ "node",
+ "Decentralization",
+ "Gas"
],
"language": "en",
"speakers": [
- "leona-hioki"
+ "jacek-glen"
],
"eventId": "devcon-7",
- "slot_start": 1731495600000,
- "slot_end": 1731497400000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1CkoCHWyFJ_4IDI_puC1cfrAXBQJADtCY7bYExgXn3xQ"
+ "slot_start": 1731572400000,
+ "slot_end": 1731573000000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Dzcuj-EPyhFVz3jUb7kd535irDd3n7X0WxNqRVI5Rgs"
},
"vector": [
- 0,
- 0,
- 0,
0,
0,
0,
@@ -819644,13 +817901,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -819775,6 +818029,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -819804,6 +818059,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -819889,6 +818145,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -819927,6 +818184,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -820224,7 +818482,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -820270,10 +818527,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
0,
0,
0,
@@ -820283,39 +818540,38 @@
},
{
"session": {
- "id": "unlocking-the-future-onboarding-the-fixed-income-market-to-ethereumchallenges-and-opportunities",
- "sourceId": "N3JJFU",
- "title": "Unlocking the Future: Onboarding the Fixed Income Market to Ethereum—Challenges and Opportunities",
- "description": "Discover how Ethereum can revolutionize the world’s largest market: fixed income. This talk will explore strategies for onboarding fixed income markets onchain by collaborating with regulators, adopting progressive compliance, and streamlining UI/UX. We'll also discuss how to tackle challenges such as chain navigation, liquidity fragmentation, and fiat-to-crypto onboarding to drive the next wave of mass adoption.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "id": "usability-changes-in-a-post-eoa-world",
+ "sourceId": "P9FRCH",
+ "title": "Usability changes in a post-EOA world",
+ "description": "The wallet world has evolved to embrace contract accounts (4337 and 7702), app-owned wallets, session keys (CAIP-25), and permissions controls (7715). How might we on the app layer design and build upon these new account types? In this talk, we will demonstrate the possibilities for novel user flows given these new account standards, compare how these new standards can introduce pitfalls, and provide best practices on how to design for app layer in a post-7702 world.",
+ "track": "Usability",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Design",
"featured": false,
"doNotRecord": false,
"keywords": [
- "DeFi"
+ "Wallet",
+ "UX"
],
"tags": [
- "Regulation",
- "UI/UX",
- "Account Abstraction",
- "Economics",
- "defi",
+ "ux",
+ "wallet",
"Account Abstraction",
- "Economics",
- "Regulation",
+ "Design",
+ "Key Management",
"UI/UX"
],
"language": "en",
"speakers": [
- "charles-st-louis"
+ "gregthegreek",
+ "cindy"
],
"eventId": "devcon-7",
- "slot_start": 1731580800000,
- "slot_end": 1731581400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/15KHZ8vK6GD9sf4oCsV5ZRJ5sKkMhq4oPgvFv-uAVHsY"
+ "slot_start": 1731573000000,
+ "slot_end": 1731574800000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Qe6obqukS9lTToSF06QtJ1Ovqj8Dzv1P-Vi0z9-wI7w"
},
"vector": [
0,
@@ -820324,6 +818580,8 @@
0,
0,
0,
+ 0,
+ 0,
6,
0,
0,
@@ -820946,6 +819204,9 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
0,
0,
0,
@@ -821010,12 +819271,12 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -821105,7 +819366,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -821114,6 +819374,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -821129,7 +819390,35 @@
0,
0,
0,
- 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -821261,59 +819550,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -821601,6 +819837,30 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 2,
+ 2,
+ 0,
0,
0,
0,
@@ -821624,6 +819884,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -821633,7 +819894,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -821641,64 +819901,52 @@
0,
2,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0
]
},
{
"session": {
- "id": "unpacking-eof-applications-in-developer-infrastructure-and-tooling",
- "sourceId": "87XNSS",
- "title": "Unpacking EOF: Applications in Developer Infrastructure and Tooling",
- "description": "In this talk, we will delve into the Ethereum Object Format (EOF), a pivotal component of the upcoming Pectra hard-fork, focusing on its profound implications for development infrastructure and tooling. EIP-7692 introduces a new execution environment and a structured format for executable code, bringing extensive changes to the Ethereum Virtual Machine (EVM).\r\n\r\nHow will it affect developers? What will make their lives harder and what easier?",
- "track": "Core Protocol",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
+ "id": "usc-ultimate-solidity-championship",
+ "sourceId": "UE8WVS",
+ "title": "USC Ultimate Solidity Championship",
+ "description": "A 30-minute Solidity programming competition where the winner is determined objectively, permissionlessly, and transparently after the time expires. The Ultimate Solidity Championship (USC) is an event designed to showcase the skills of the best Solidity developers in the ecosystem. Its primary goals are to highlight Solidity programming as an art form, onboard more developers, educate the community, and foster collaboration, ultimately enhancing Ethereum's long-term impact.",
+ "track": "Entertainment",
+ "type": "Mixed Formats",
+ "expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "EOF",
- "EIP-7692",
- "EVM"
+ "Solidity",
+ "Programming",
+ "Competition"
],
"tags": [
- "Core Protocol",
- "Developer Infrastructure",
- "DevEx",
- "EVM",
- "Core Protocol",
- "Developer Infrastructure",
- "DevEx"
+ "Art",
+ "Hacks",
+ "Public good"
],
"language": "en",
"speakers": [
- "nebojsa-urosevic",
- "pavle-drobnjak"
+ "five"
],
"eventId": "devcon-7",
- "slot_start": 1731562200000,
- "slot_end": 1731562800000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1yIsFqKcISo1wBOpMh8bQqTwKa7ihE8HDSAKmoWXYRs8"
+ "slot_start": 1731582000000,
+ "slot_end": 1731583800000,
+ "slot_roomId": "classroom-b",
+ "resources_presentation": "https://docs.google.com/presentation/d/1flrl1DVDOcGQrL2WtGO0tRQUbwP7P_Xk3IQeWVr_wIU"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -822387,8 +820635,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -822460,7 +820706,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -822471,7 +820716,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -822495,7 +820739,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -822551,6 +820794,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -822648,7 +820893,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -822692,6 +820936,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -823002,9 +821247,9 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
0,
2,
0,
@@ -823024,39 +821269,39 @@
},
{
"session": {
- "id": "updating-gas-cost-schedule-based-on-reproducible-benchmarks",
- "sourceId": "TZVK7F",
- "title": "Updating Gas Cost Schedule based on reproducible benchmarks",
- "description": "Sponsored by the Ethereum Foundation, our project evaluates the real cost of executing OPCODEs and procompiles in EVMs across diverse clients. We present the up-to-date benchmarks, the new Gas Cost Schedule proposal, a do-it-yourself solution to reproduce measurements in your environment, and an automated way to generate new proposals for each hard fork.",
+ "id": "using-reth-execution-extensions-for-next-generation-indexing",
+ "sourceId": "YUFRTQ",
+ "title": "Using Reth Execution Extensions for next generation indexing",
+ "description": "Recently, Reth and Geth released the ExEx and live tracer features, respectively, which share similar functionalities. Both provide real-time, detailed access to chain and state events. As ExEx developers begin to persist this data and explore ways to make it accessible to users, new questions arise: how can we best serve this data to users, and what might the indexers of the future look like?",
"track": "Core Protocol",
- "type": "Lightning Talk",
+ "type": "Talk",
"expertise": "Intermediate",
- "audience": "Community",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Gas Cost Schedule",
- "EVM Internals",
- "Client Diversity",
- "Node Infrastructure"
+ "client",
+ "plugin",
+ "indexer"
],
"tags": [
- "Gas",
- "Decentralization",
- "infrastructure",
- "node",
- "Decentralization",
- "Gas"
+ "Layer 1",
+ "Developer Infrastructure",
+ "Tooling",
+ "plugin",
+ "Developer Infrastructure",
+ "Layer 1",
+ "Tooling"
],
"language": "en",
"speakers": [
- "jacek-glen"
+ "alexey-shekhirin"
],
"eventId": "devcon-7",
- "slot_start": 1731572400000,
- "slot_end": 1731573000000,
+ "slot_start": 1731484800000,
+ "slot_end": 1731486600000,
"slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1Dzcuj-EPyhFVz3jUb7kd535irDd3n7X0WxNqRVI5Rgs"
+ "resources_presentation": "https://docs.google.com/presentation/d/1grvRBeTUC4cPjxwSFQPy6d3VmlJ6P3Y2_R99fgeourE"
},
"vector": [
0,
@@ -823757,8 +822002,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -823825,11 +822068,13 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -823862,6 +822107,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -823883,8 +822129,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -823913,7 +822157,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -823999,7 +822242,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -824039,7 +822281,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -824349,6 +822590,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -824376,12 +822618,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -824394,35 +822636,41 @@
},
{
"session": {
- "id": "usc-ultimate-solidity-championship",
- "sourceId": "UE8WVS",
- "title": "USC Ultimate Solidity Championship",
- "description": "A 30-minute Solidity programming competition where the winner is determined objectively, permissionlessly, and transparently after the time expires. The Ultimate Solidity Championship (USC) is an event designed to showcase the skills of the best Solidity developers in the ecosystem. Its primary goals are to highlight Solidity programming as an art form, onboard more developers, educate the community, and foster collaboration, ultimately enhancing Ethereum's long-term impact.",
- "track": "Entertainment",
- "type": "Mixed Formats",
- "expertise": "Beginner",
+ "id": "utilizing-national-ids-in-the-ethereum-ecosystem",
+ "sourceId": "PR78EL",
+ "title": "Utilizing national IDs in the Ethereum ecosystem",
+ "description": "This panel brings together developers of MynaWallet, Anon-Aadhaar, Proof of Passport and zkPassport, who are exploring and developing applications that utilize government-issued IDs in the Ethereum ecosystem. We will discuss the characteristics of each ID system and what functions can be realized using tech stacks in the Ethereum ecosystem and cryptographic technology.",
+ "track": "Real World Ethereum",
+ "type": "Panel",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Solidity",
- "Programming",
- "Competition"
+ "National IDs",
+ "Selective Disclosure"
],
"tags": [
- "Art",
- "Hacks",
- "Public good"
+ "Civil Resistance",
+ "Privacy",
+ "Identity",
+ "Civil Resistance",
+ "Identity",
+ "Privacy"
],
"language": "en",
"speakers": [
- "five"
+ "yanis",
+ "michael-elliot",
+ "hiroyuki-tachibana",
+ "florent",
+ "nico"
],
"eventId": "devcon-7",
- "slot_start": 1731582000000,
- "slot_end": 1731583800000,
- "slot_roomId": "classroom-b",
- "resources_presentation": "https://docs.google.com/presentation/d/1flrl1DVDOcGQrL2WtGO0tRQUbwP7P_Xk3IQeWVr_wIU"
+ "slot_start": 1731552300000,
+ "slot_end": 1731555900000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1DNOsJyO6qTZrHr9rXUHPF9-HZEOF4NkaTmABCndOG0g"
},
"vector": [
0,
@@ -824431,11 +822679,10 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -824534,6 +822781,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -824594,6 +822842,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -825122,6 +823372,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -825219,6 +823471,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -825286,7 +823539,6 @@
0,
0,
2,
- 2,
0,
0,
0,
@@ -825399,6 +823651,39 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -825428,46 +823713,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -825738,9 +823983,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
2,
0,
@@ -825760,52 +824005,47 @@
},
{
"session": {
- "id": "using-reth-execution-extensions-for-next-generation-indexing",
- "sourceId": "YUFRTQ",
- "title": "Using Reth Execution Extensions for next generation indexing",
- "description": "Recently, Reth and Geth released the ExEx and live tracer features, respectively, which share similar functionalities. Both provide real-time, detailed access to chain and state events. As ExEx developers begin to persist this data and explore ways to make it accessible to users, new questions arise: how can we best serve this data to users, and what might the indexers of the future look like?",
- "track": "Core Protocol",
+ "id": "vadcops-leveraging-starks-for-tailored-proof-generation",
+ "sourceId": "BEJPG8",
+ "title": "VADCOPs: Leveraging STARKs for Tailored Proof Generation",
+ "description": "VADCOP is a proving method using STARKs to achieve cost-efficiency by focusing on active parts of the execution trace rather than the entire trace. Traditional modular designs, which divide machines into components and use relational arguments, face inefficiencies due to the padding of unused cells with dummy values. VADCOPs optimize performance by allowing maximum modularity and avoiding unused components, making proof generation precise and efficient without unnecessary redundancy.",
+ "track": "Applied Cryptography",
"type": "Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "client",
- "plugin",
- "indexer"
+ "STARKs",
+ "VADCOPs",
+ ""
],
"tags": [
- "Layer 1",
- "Developer Infrastructure",
- "Tooling",
- "plugin",
- "Developer Infrastructure",
- "Layer 1",
- "Tooling"
+ "vadcops"
],
"language": "en",
"speakers": [
- "alexey-shekhirin"
+ "hector-masip-ardevol",
+ "felicia-barcelo"
],
"eventId": "devcon-7",
- "slot_start": 1731484800000,
- "slot_end": 1731486600000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1grvRBeTUC4cPjxwSFQPy6d3VmlJ6P3Y2_R99fgeourE"
+ "slot_start": 1731479400000,
+ "slot_end": 1731481200000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1vlLbALGk1-PoxsWpK3hZ1d85x7eK1bnX8dA5Jjf4Yj0"
},
"vector": [
0,
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -826497,6 +824737,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -826562,13 +824803,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -826601,7 +824840,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -827107,7 +825345,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -827130,50 +825367,44 @@
},
{
"session": {
- "id": "utilizing-national-ids-in-the-ethereum-ecosystem",
- "sourceId": "PR78EL",
- "title": "Utilizing national IDs in the Ethereum ecosystem",
- "description": "This panel brings together developers of MynaWallet, Anon-Aadhaar, Proof of Passport and zkPassport, who are exploring and developing applications that utilize government-issued IDs in the Ethereum ecosystem. We will discuss the characteristics of each ID system and what functions can be realized using tech stacks in the Ethereum ecosystem and cryptographic technology.",
- "track": "Real World Ethereum",
- "type": "Panel",
- "expertise": "Intermediate",
+ "id": "verifiable-open-source-vaccines-to-save-millions-of-lives-from-the-developing-world-up",
+ "sourceId": "S7LEHK",
+ "title": "Verifiable Open Source Vaccines to Save Millions of Lives from the Developing World Up",
+ "description": "Viruses & bacteria like HCV, Strep A, and TB cumulatively take millions of lives each year – effective vaccines against them would considerably reduce that death toll. Unfortunately, big pharma isn’t interested in investing in developing these vaccines, and even if they did exist, rising vaccine hesitancy may prevent many from benefitting. PopVax is pioneering a new model of developing first-in-the-world verifiable vaccines at dramatically lower cost in India with radically greater transparency.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "National IDs",
- "Selective Disclosure"
+ "vaccines",
+ "biotech",
+ "public health"
],
"tags": [
- "Civil Resistance",
- "Privacy",
- "Identity",
- "Civil Resistance",
- "Identity",
- "Privacy"
+ "DeSci",
+ "Effective Altruism",
+ "Public good"
],
"language": "en",
"speakers": [
- "yanis",
- "michael-elliot",
- "hiroyuki-tachibana",
- "florent",
- "nico"
+ "soham-sankaran"
],
"eventId": "devcon-7",
- "slot_start": 1731552300000,
- "slot_end": 1731555900000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1DNOsJyO6qTZrHr9rXUHPF9-HZEOF4NkaTmABCndOG0g"
+ "slot_start": 1731572400000,
+ "slot_end": 1731573300000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1sK71lOtl_9Q8SbWOBVtDNhLVBhc--pIc-AxaYE2toIM"
},
"vector": [
0,
+ 6,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -827276,7 +825507,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -827337,8 +825567,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -827869,12 +826097,11 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -827968,7 +826195,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -828030,12 +826256,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -828055,6 +826281,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -828149,7 +826376,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -828166,6 +826392,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -828480,9 +826707,10 @@
0,
0,
0,
- 2,
0,
0,
+ 2,
+ 0,
0,
2,
0,
@@ -828502,43 +826730,46 @@
},
{
"session": {
- "id": "vadcops-leveraging-starks-for-tailored-proof-generation",
- "sourceId": "BEJPG8",
- "title": "VADCOPs: Leveraging STARKs for Tailored Proof Generation",
- "description": "VADCOP is a proving method using STARKs to achieve cost-efficiency by focusing on active parts of the execution trace rather than the entire trace. Traditional modular designs, which divide machines into components and use relational arguments, face inefficiencies due to the padding of unused cells with dummy values. VADCOPs optimize performance by allowing maximum modularity and avoiding unused components, making proof generation precise and efficient without unnecessary redundancy.",
- "track": "Applied Cryptography",
- "type": "Talk",
+ "id": "verifier-alliance-inside-of-the-contract-verification-pipeline",
+ "sourceId": "Q3EDF8",
+ "title": "Verifier Alliance: inside of the contract verification pipeline",
+ "description": "The talk will guide you through a smart-contract verification process step by step while introducing some technical details and challenges verification services have to handle. Will describe what we have learned building \"Verifier Alliance\" - a new collective that unites different verification providers to have an open and shared database of smart contracts (verifieralliance.org).",
+ "track": "Developer Experience",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "STARKs",
- "VADCOPs",
- ""
- ],
"tags": [
- "vadcops"
+ "DevEx",
+ "verification",
+ "contracts",
+ "DevEx"
],
- "language": "en",
- "speakers": [
- "hector-masip-ardevol",
- "felicia-barcelo"
+ "keywords": [
+ "Contract",
+ "Verification"
],
+ "duration": 519,
+ "language": "en",
+ "sources_swarmHash": "69a3730194c47cec0c3005a9eed1c4f8dd9c959160dc3ba772e0007bc7847a61",
+ "sources_youtubeId": "2U4Wad2ebwI",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343ad99dbb7a90e19c6d6f.vtt",
+ "transcript_text": " All right, thanks for coming to my talk. So this is a talk on L2 composability from Collaborative Snarks, or in other words, how do we synchronously compose but also retain horizontal scalability at the same time? So Web3 is all about composability, at least in my view. It's about composable money, I guess. Traditional web applications have been independently operated. You need to trust an operator. They communicate and interact asynchronously. And a lot of what we think about in terms of Web3 is the security or the decentralization. But in my view, the thing that comes from decentralization is enabling everyone to trust a common distributed virtual machine that the entire world can use and what is the consequence of that? What is the benefit of that? Well, the benefit of that is that all applications can run on the same system and they can compose with each other and that's like the meaningful difference to an end user or one of the meaningful differences to an end user and that's what enables um you know so much innovation to thrive uh and as we call it ethereum's infinite garden to to thrive um and so um you know the the it even enables new applications that just never existed in the world of uh of asynchronous systems before such as a flash loan, where you can have a lending application that is designed completely independently of these decentralized exchanges, even two different decentralized exchanges, and now suddenly you can have a user create a single transaction that interacts with all these applications to borrow money, do some things with it, and return it all in the same transaction. And obviously there's so much more that you can do besides flash loans, but this is what I'd like to use as the example of what we can do with composability that we just couldn't do in the world before. Now, of course, roll-ups have been amazing for scaling Ethereum, making it more performant. They horizontally scale Ethereum. A multi-chain world was born out of this need to scale. And the advantages that it brings are, one, charting of computation across different applications. It also allows powerful nodes, because the Internet is not homogeneous, but heterogeneous. And if you have millions of nodes participating in a system, then there's going to be more powerful ones and weaker ones. Well, rollups enable powerful nodes to help weaker nodes verify state. And it also allows for virtual machine diversity. So there are many, many, many benefits. But one of the things that came out of a multi-chain world on Ethereum is that we no longer have composability of applications across these different chains. So what is composability? Composability isn't something that is perfectly well defined. I take sort of a holistic view on composability. It could refer to things like bridging of assets, like moving ETH from one chain to another. There are higher forms of composability that can be enabled by sending cross-chain messages and having dependencies between actions on different chains. And you can have even cross-chain function calls, which are the way that applications interact within the same virtual machine, and one application can actually call a function on another application. And one way to look at how to define the highest form of composability which I call synchronous composability is through the framework of of ACID transactions in traditional database systems. So in a synchronously composable cluster of chains users should be able to express cross-chain transactions or intents, such as their intent to atomically swap something or borrow funds from one chain, do something another chain and return the money, that have this ACID property, which is atomicity, all parts of the transaction complete or none due. There's no in-between state that's reached or observable. Consistency, so the rules of each chain are preserved. Isolation, different cross-chain transactions or transactions to independent chains, they don't interfere with each other. And so in particular what this means is that if you're in the middle of executing an atomic swap, another transaction shouldn't be able to observe the fact that that atomic swap, another transaction shouldn't be able to observe the fact that that atomic swap hasn't completed yet. So traditional atomic swaps do not have this isolation property because they involve locking an asset on one chain, waiting a long time for something to happen on the other chain, and then eventually resolving it. In fact, atomic swaps have this liveness risk where if one of the chains loses liveness, you can even break the atomicity. And of course, durability, which is basically just that there's consensus on a persistent global transaction lock. So consistency and durability are just inherited from the fact that we're running on blockchains. But the two key things are atomicity and isolation, and those are not achieved by sort of asynchronous ways of composing different chains. So what is the easiest way to asynchronously pass messages between chains? Well, it's via the layer one. So this is the rough idea. You have a roll-up. A roll-up can have basically a mailbox. I like to describe it as an outbox and an inbox. And it can write messages to its outbox that should be read by the other chain. And you can actually have, you know, the sequencer of the chain basically just fill the inbox of one chain by reading from the outbox of the other chain and providing a proof to its inbox that can be verified against the Merkle root of the outbox of the other chain. Of course, there's different ways you can actually implement this. This would just be one way of implementing it. But this is, you know, essentially if you're familiar with, like, RIP 7755 or other things that are being discussed, like, this is roughly, you know, the most straightforward way of passing messages between rollups without introducing additional assumptions on off-chain oracles or anything. Just using the L1. Now, the downside of this, of course, is that in order for Rollup B to read a message from Rollup A, it needs to wait for Rollup A to not only finalize its transactions by posting to Ethereum and waiting for Ethereum finality, which is about 12 to 15 minutes, but it needs to be able to trust that Merkle route, and so that requires waiting the settlement time of rollup A which could be multiple days if rollup A is an optimistic rollup. So this way of passing messages via the L1 takes a very long time. It can take multiple days. So cross-chain transactions, they have very high latency, long wait before a chain can read a message from another chain. The other thing that asynchronous message passing via the L1 doesn't achieve is it doesn't achieve this asset property for cross-chain transactions. So there's another way of passing messages, potentially faster. And so this is a slight change. What we're going to do here is we won't wait for verifying a message against a Merkle root, but rather the sequencers will just be allowed to fill the inboxes with messages that were allegedly written to the outboxes of the other chains, and just sort of optimistically accept them, process them, and only at settlement time will we do anything to check that the messages that were written to the outbox of the first chain are consistent with the messages that were written to the inbox of the second chain. So this requires a change in the way that rollups settle. It requires this coordinated settlement, or aggregated settlement, as some people call it. And this could, for example, be just implemented as a cross-check on the L1 between the Merkle roots of the two different mailboxes. Or we could involve some kind of aggregator that creates ZK proofs of the two different chains and actually proves the consistency of the mailboxes as well. Now, the advantage of this is that the rollups don't have to wait for multiple days in order to ingest a message from the other chain. Of course, if they're given an incorrect message, then they will experience... I mean, when they go to settle, it won't work. So it's sort of like when you create an invalid block for a ZK roll-up, and then the proof can't be created, and then you would have to go back to where you were before. It's not technically a reorg, but the full nodes could become confused for some period of time. But optimistically, you would just be able to make progress really fast, right? And you still have the security of the L1. Now, when you're passing messages this way, you're still not able to achieve ACID cross-chain transactions because, you know, let's say you were trying to use this in order to achieve some kind of atomic swap, you would send a message to another chain that you locked an asset, you would wait for a message back, you know, verifying some event on the other chain. In that interim time, you're in these locked intermediary states, that's observable, so you don't really have this ACID property. For this ACID property to hold, you need something called synchronous composability. Okay, so why are ACID cross-chain transactions so hard to achieve? Well, you need to be able to emulate multiple rounds of communication. You need to be able to do something, send a message to another chain, and wait for a response back. And that all needs to happen within one block. That can't happen across multiple blocks. There's also an inherent dependency on the global ordering of transactions across all chains of the individual transactions on those chains. If you're sending multiple rounds of communication, then the relative ordering of these different transactions on the different chains will have an impact on what happens. Now, of course, there's a naive solution, which is just to merge all chains into one, and that would certainly achieve this ACID property, right? That's a naive straw man. But the reason why this is hard to do in this, you know, is very much because of the constraint that we want to retain efficiency. We want to preserve horizontal scaling. So on its own, ACID is not hard to achieve. It's hard to achieve it in a way that preserves scalability. And so one way to sort of make this a bit more precise is to view this through the lens of collaborative snarks. Snarks, for those of you who aren't familiar with the term, are just the technical term for ZK proofs. ZK proofs, at least the ones that we use in the blockchain world, are succinct, non-interactive proofs of knowledge. Rollups don't even use the zero knowledge property, so it's just sort of a misnomer that we ended up calling them ZK proofs. But Snarks are the same things as ZK proofs. So there's this implicit, whenever you have chains interacting, there's this implicit unified virtual machine in which the cross-chain transactions, it's a tongue twister, take place. And so the goal is really to create some kind of single ZK proof of a state transition for a distributed system of virtual machines with this inter-process communication where we introduce one prover per virtual machine, and the total work done per prover should remain near constant as the number of interacting virtual machines grows. So that's sort of the goal of being able to preserve the scalability, the fact that the total work done per prover, per chain, remains near constant. It doesn't grow, you know, as linearly as the number of chains grows. And in other words, the total amount of work being done in the system is linear, and the number of provers is not quadratic. So we actually can apply generic solutions to this. There are generic ways of just having all the provers for the different chains collaborate on creating a distributed SNARK for the unified VM that, you know, is their composition. You can use SNARK recursion for this. There's other ways of doing it through distributed SNARK protocols, like something called distributed sum check, distributed FFTs. So, you know, it's not typically the way that we think about it. We think about provers being sort of their job is to just create proofs for their own roll-up, but maybe the goal should actually just be that the overall work should, you know, be horizontally scalable. But I'm going to present today sort of what you can be viewed as a special case of this, but it's a lot closer to the model in which rollups interoperate and act today. And it's just a simple extension of the asynchronous message mailbox design that I presented at the beginning. So we still have the outbox and inboxes on the two different chains, but the key difference here is that instead of chains writing to their outbox and then in the next block being able to read a bunch of messages that were populated to their inbox, ostensibly that should match the messages written to the outbox to the other chain in the previous block, that's how we did it before, there's going to be a coordinator that can just figure out, okay, these are the messages that this other chain is writing to its outbox, by simulating the execution, and I'm going to provide you with those messages. And so these two blocks are constructed at the very same time. Chains are really just verifying execution, they're not, they don't need to carry out the execution themselves, constructed at the very same time. Chains are really just verifying execution. They don't need to carry out the execution themselves. The execution is carried out by builders who are building the blocks, in this case a coordinator. This coordinator simulates the execution. So I can walk through an example. You can have a transaction on rollup A that basically borrows funds from some contract. It burns them. It writes a message to its outbox that they were burned. And then immediately reads a message from its inbox that something happened on the other side. A lot of things happened in the middle over there, but they just weren't observable to this chain. So it immediately reads that messages were then minted on the other side. In the meantime, what happened was on rollup B, there was a message that was provided in the inbox that said, oh, funds were burned on rollup A. It then did a bunch of things, maybe multiple swaps at desired prices, made some profit, and then burned the funds, wrote that message to its outbox. That message was provided by the coordinator to the inbox of rollup A, causing this transaction to complete. the refunds were returned. Now, if there was any inconsistency, if some message was written to the outbox B but that wasn't put in the inbox A, then that would be caught at settlement time. As we showed, when the roll-ups settle, all we need to do is make sure that the outboxes of chain A matches the inbox of chain B and vice versa. The outbox of chain B matches the inbox of chain A. So that provides you the intuition. We have a full protocol on this called Coordinated Inter-Rollup Communication. It's not fully general, but it covers most practical use cases of synchronous composability among independent chains, like flash loans, which I just showed the example of, It is not fully general, but it covers most practical use cases of synchronous composability among independent chains, like flash loans, which I just showed the example of, asset swaps, limit orders, basically anything that we can really think of. It would be interesting to see if people come up with use cases that are practical that aren't covered. It doesn't require any VM modifications to the chains. You just need to implement these contracts as mailboxes as contracts. And it enables parallel proving. So each L2 prover just independently proves its own state. It proves what the Merkle root of its mailbox is. And then there's an aggregator that creates a simple aggregated proof whose complexity is completely independent of the complexity of each chain. These mailboxes are implemented as contracts. They use authent are implemented as contracts. They use authenticated key value maps. And, you know, any contract can basically write to the app box or read from the inbox. But you index it by which contract wrote. So it doesn't allow contracts to sort of conflict with each other and overwrite each other. And then you have the settlement layer contract that basically just verifies the correctness of state updates from each roll-up and checks the mailbox consistency by verifying this aggregated proof. So this is what it looks like. We have this aggregator, just like before. It's exactly like the asynchronous setting, it's just that we have this coordinator, which could be, for example, a shared sequencer that figures out what messages are being communicated between the two chains, could be multiple rounds of messages, and provides those messages ahead of time, pre-populates the inboxes of the two different chains with the messages that they should be receiving over multiple rounds of communication. Now, one important variantant of roll-ups is that full nodes should always know the state. Once a sequencer posts a transaction ordering, full nodes should be able to immediately calculate the roll-up state. They shouldn't have to wait for L1 settlement. Waiting for L1 finality of the sequencer published blocks is generally sufficient. And if the sequencer is trusted not to change its mind about what it's going to post, then full nodes should be able to trust a pre-confirmation from the sequencer within seconds. Now, the problem is that this protocol circ sort of breaks that property unless it you know, if done naively. And the issue is that because the rollups are now interacting, the full nodes of rollup A who are ostensibly only executing for rollup A, they don't really know the state of rollup A until they can trust that the messages the coordinator provided are correct. And it won't really know that until settlement time. So how do we, yeah, how do we solve that issue? are correct and it won't really know that until settlement time. So how do we solve that issue? That's problem number one. Problem number two is that normally you can trust a sequencer for fast confirmations. Here this coordinator, which is going to be coordinating the mailbox constructions across many, many different chains, becomes a single point of failure. And so, you know, maybe the full nodes of Arbitrum can trust the Arbitrum centralized sequencer, and the Optimism full nodes can trust the Optimism sequencer, but it's hard to trust one sequencer for confirmations when multiple chains are interacting. The solution is to fold, one, make ZK-Proofs faster that can be communicated offline really fast, and two, use the fast confirmation layer. So a fast confirmation layer is basically a BFT consensus protocol that reaches finality faster than the L1 and ensures that whatever was finalized by the consensus protocol, you know, has to be what's eventually posted to the L1. Fast off-chain ZK proofs are interesting because the goal here is to optimize the end-to-end latency of proving. You know, and proving proof aggregation verification given the constraints on the bandwidth and compute power of each full node. And so it motivates different design constraints than when we're just trying to have ZK proofs optimized for L1 settlement. Because the bandwidth and compute requirements of L2 nodes could be different. And so we could consider using SNARKs with larger communication, but faster proofs, like Orion, Breakdown, BaseFold, Blaze, or a number of other systems. So anyways, this is what it looks like putting it all together. You have some shared sequencer that coordinates the mailbox construction. The blocks are sent to a confirmation layer. They're confirmed. Rollup A and Rollup B provers and create these proofs. And then you have some kind of aggregated settlement. And this is how you enable chains to either have very fast asynchronous communication or even synchronous communication that enables synchronous composability. So thank you very much, and I will go on to the questions. Good stuff, Ben. Very technical. I think we've got time for a few questions. So the first one that's on there is the coordinator of two roll-ups needs to be synced to both of them, right? In other words, he needs to be executing both rollups himself. That's correct. Okay. That was an easy one. Easy. And what happens if the message box says fork before settlement? Wouldn't the nodes be reading just one rollup, be lost until settlement? Which one is this? Oh, now it's number two. Okay. What happens if the message box is fork? Okay, social wants to be the shared player for all of us. I think I'm seeing different questions than you are. Oh, the second one. What happens if the message box is forked before settlement? So the message boxes don't fork before settlement. I mean, so the chains need to have something that is used for their, you know, as their sort of finality layer. You can, of course, wait for L1 finality on the blocks that were published. So you publish the blocks to the L1. That's pre-settlement time. Or if you have a fast confirmation layer, such as the one that Espresso Network provides, right, then you would be publishing those blocks to that fast confirmation layer and then you would ensure that whatever is posted at settlement time is consistent with that. Ultimately, you can define the rules or constraints of what constrains the roll-ups before settlement time, but at settlement time, you would be posting a collection of blocks for the different roll-ups that are consistent with each other in terms of these mailbox consistency checks and consistent with the rules of those roll-ups for what was finalized on different various layers before that settlement time. Okay, the next question. It voted up while it was up there. A little spicy. Espresso wants to be the shared layer for roll-ups but lacks credible neutrality. It voted up while it was up there, a little spicy. Yeah. Espresso wants to be the shared layer for roll-ups, but lacks credible neutrality. How keen is Espresso on jointly designing the shared layer with roll-ups? So, yeah. So Espresso has been designing this, you know, sort of confirmation layer, as we call it, which it doesn't do everything that I described today. It provides this fast confirmation layer that rollups can use. Today the Espresso network, in fact, is live on mainnet. And we have been building towards creating infrastructure that rollups can use to enhance their composability. And we've been doing it very much in collaboration and taking feedback from, you know, from roll-ups, just like DA layers, et cetera. Okay, the next one, something that I've seen when I was briefly working with roll-ups on the DevOps side, is that how can cross-chain message passing happen if roll-ups have different latencies and hardly can be viewed as synchronized, especially with AMMs protocols being strictly arbitrage and asynchronous? It's like some that post once a day and some that post once an hour. Right, so how can cross-chain message passing happen if rollups have different latencies and hardly can be viewed as synchronized? So if rollups... So first of all, I presented two different kinds of modes of communication. So there's asynchronous communication and synchronous communication. If the roll-ups is not about, it's not actually, it's not the latencies that matters. It's the block times of the roll-ups. So the block times are different, and you can still communicate asynchronously. If the block times are not synced, then you can't communicate synchronously. So you would have to synchronize the block times, but you can also have different size blocks on the different rollups.",
"eventId": "devcon-7",
- "slot_start": 1731479400000,
- "slot_end": 1731481200000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1vlLbALGk1-PoxsWpK3hZ1d85x7eK1bnX8dA5Jjf4Yj0"
+ "slot_start": 1731472800000,
+ "slot_end": 1731473400000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1WNKyHeXOwkXmvaf0GIGfAtO5R7MQYyUbdRwxgk23ZzQ",
+ "resources_slides": null,
+ "speakers": [
+ "rim-rakhimov"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -829236,58 +827467,6 @@
0,
0,
0,
- 6,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -829295,6 +827474,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -829369,6 +827549,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -829597,6 +827778,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -829757,6 +827939,57 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -829822,7 +828055,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -829845,7 +828077,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -829855,6 +828086,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -829867,39 +828102,46 @@
},
{
"session": {
- "id": "verifiable-open-source-vaccines-to-save-millions-of-lives-from-the-developing-world-up",
- "sourceId": "S7LEHK",
- "title": "Verifiable Open Source Vaccines to Save Millions of Lives from the Developing World Up",
- "description": "Viruses & bacteria like HCV, Strep A, and TB cumulatively take millions of lives each year – effective vaccines against them would considerably reduce that death toll. Unfortunately, big pharma isn’t interested in investing in developing these vaccines, and even if they did exist, rising vaccine hesitancy may prevent many from benefitting. PopVax is pioneering a new model of developing first-in-the-world verifiable vaccines at dramatically lower cost in India with radically greater transparency.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "id": "verkle-integration-in-reth",
+ "sourceId": "T8LKTM",
+ "title": "Verkle integration in reth",
+ "description": "This talk concerns the presentation of EPF Project: Verkle integration in reth.\r\nThe project comprised of replacing the current state-commitment structure in reth with verkle tries and other modifications for statelessness, including implementing EIPs such as EIP-4762: Statelessness gas cost changes (to REVM), EIP-6800: Ethereum State using a unified verkle trie, EIP-7709: Read BLOCKHASH from storage and update cost, and passing the associated execution-spec-test vectors designed for these EIPs.",
+ "track": "[CLS] EPF Day",
"type": "Lightning Talk",
- "expertise": "",
- "audience": "Engineering",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "vaccines",
- "biotech",
- "public health"
- ],
"tags": [
- "DeSci",
- "Effective Altruism",
- "Public good"
+ "EPF",
+ "Core Protocol",
+ "Cryptography",
+ "Verkle trees"
],
- "language": "en",
- "speakers": [
- "soham-sankaran"
+ "keywords": [
+ "Stateless clients",
+ "Verge"
],
+ "duration": 871,
+ "language": "en",
+ "sources_swarmHash": "4c3add1def5321ff44e6a128ca79299c6b8f9c3c4c274d2d79412d0bcf266853",
+ "sources_youtubeId": "b7JdDe2kW98",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731572400000,
- "slot_end": 1731573300000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1sK71lOtl_9Q8SbWOBVtDNhLVBhc--pIc-AxaYE2toIM"
+ "slot_start": 1731472200000,
+ "slot_end": 1731473100000,
+ "slot_roomId": "breakout-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Uq2DzZBnDwPSfrV2xqfm-mlie2DOZZKEwi0Kk44YlQI",
+ "resources_slides": null,
+ "speakers": [
+ "aditya-gupta"
+ ]
},
"vector": [
- 0,
- 6,
0,
0,
0,
@@ -829915,6 +828157,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -830661,11 +828904,13 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -830759,9 +829004,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -830784,7 +829026,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -830843,6 +829084,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -830896,7 +829138,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -830953,6 +829194,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -831210,9 +829452,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
2,
@@ -831227,54 +829469,34 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "verifier-alliance-inside-of-the-contract-verification-pipeline",
- "sourceId": "Q3EDF8",
- "title": "Verifier Alliance: inside of the contract verification pipeline",
- "description": "The talk will guide you through a smart-contract verification process step by step while introducing some technical details and challenges verification services have to handle. Will describe what we have learned building \"Verifier Alliance\" - a new collective that unites different verification providers to have an open and shared database of smart contracts (verifieralliance.org).",
- "track": "Developer Experience",
+ "id": "viruses-and-chronic-aging-building-a-research-community",
+ "sourceId": "FX8UQF",
+ "title": "Viruses and Chronic Aging: Building a Research Community",
+ "description": "Did you know that mitochondrial dysfunction, inflammation, and cognitive decline are directly accelerated by viruses? In fact, the viruses that infect us over a lifetime are technically not even alive, and therefore must “hack” our human cellular metabolism machinery to do anything at all. This talk will overview the first-ever global collaborative network studying & treating chronic viruses as drivers of aging, including how certain lifespan-promoting drugs may help combat viral activity.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Developer",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "tags": [
- "DevEx",
- "verification",
- "contracts",
- "DevEx"
- ],
- "keywords": [
- "Contract",
- "Verification"
- ],
- "duration": 519,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "69a3730194c47cec0c3005a9eed1c4f8dd9c959160dc3ba772e0007bc7847a61",
- "sources_youtubeId": "2U4Wad2ebwI",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67343ad99dbb7a90e19c6d6f.vtt",
- "transcript_text": " All right, thanks for coming to my talk. So this is a talk on L2 composability from Collaborative Snarks, or in other words, how do we synchronously compose but also retain horizontal scalability at the same time? So Web3 is all about composability, at least in my view. It's about composable money, I guess. Traditional web applications have been independently operated. You need to trust an operator. They communicate and interact asynchronously. And a lot of what we think about in terms of Web3 is the security or the decentralization. But in my view, the thing that comes from decentralization is enabling everyone to trust a common distributed virtual machine that the entire world can use and what is the consequence of that? What is the benefit of that? Well, the benefit of that is that all applications can run on the same system and they can compose with each other and that's like the meaningful difference to an end user or one of the meaningful differences to an end user and that's what enables um you know so much innovation to thrive uh and as we call it ethereum's infinite garden to to thrive um and so um you know the the it even enables new applications that just never existed in the world of uh of asynchronous systems before such as a flash loan, where you can have a lending application that is designed completely independently of these decentralized exchanges, even two different decentralized exchanges, and now suddenly you can have a user create a single transaction that interacts with all these applications to borrow money, do some things with it, and return it all in the same transaction. And obviously there's so much more that you can do besides flash loans, but this is what I'd like to use as the example of what we can do with composability that we just couldn't do in the world before. Now, of course, roll-ups have been amazing for scaling Ethereum, making it more performant. They horizontally scale Ethereum. A multi-chain world was born out of this need to scale. And the advantages that it brings are, one, charting of computation across different applications. It also allows powerful nodes, because the Internet is not homogeneous, but heterogeneous. And if you have millions of nodes participating in a system, then there's going to be more powerful ones and weaker ones. Well, rollups enable powerful nodes to help weaker nodes verify state. And it also allows for virtual machine diversity. So there are many, many, many benefits. But one of the things that came out of a multi-chain world on Ethereum is that we no longer have composability of applications across these different chains. So what is composability? Composability isn't something that is perfectly well defined. I take sort of a holistic view on composability. It could refer to things like bridging of assets, like moving ETH from one chain to another. There are higher forms of composability that can be enabled by sending cross-chain messages and having dependencies between actions on different chains. And you can have even cross-chain function calls, which are the way that applications interact within the same virtual machine, and one application can actually call a function on another application. And one way to look at how to define the highest form of composability which I call synchronous composability is through the framework of of ACID transactions in traditional database systems. So in a synchronously composable cluster of chains users should be able to express cross-chain transactions or intents, such as their intent to atomically swap something or borrow funds from one chain, do something another chain and return the money, that have this ACID property, which is atomicity, all parts of the transaction complete or none due. There's no in-between state that's reached or observable. Consistency, so the rules of each chain are preserved. Isolation, different cross-chain transactions or transactions to independent chains, they don't interfere with each other. And so in particular what this means is that if you're in the middle of executing an atomic swap, another transaction shouldn't be able to observe the fact that that atomic swap, another transaction shouldn't be able to observe the fact that that atomic swap hasn't completed yet. So traditional atomic swaps do not have this isolation property because they involve locking an asset on one chain, waiting a long time for something to happen on the other chain, and then eventually resolving it. In fact, atomic swaps have this liveness risk where if one of the chains loses liveness, you can even break the atomicity. And of course, durability, which is basically just that there's consensus on a persistent global transaction lock. So consistency and durability are just inherited from the fact that we're running on blockchains. But the two key things are atomicity and isolation, and those are not achieved by sort of asynchronous ways of composing different chains. So what is the easiest way to asynchronously pass messages between chains? Well, it's via the layer one. So this is the rough idea. You have a roll-up. A roll-up can have basically a mailbox. I like to describe it as an outbox and an inbox. And it can write messages to its outbox that should be read by the other chain. And you can actually have, you know, the sequencer of the chain basically just fill the inbox of one chain by reading from the outbox of the other chain and providing a proof to its inbox that can be verified against the Merkle root of the outbox of the other chain. Of course, there's different ways you can actually implement this. This would just be one way of implementing it. But this is, you know, essentially if you're familiar with, like, RIP 7755 or other things that are being discussed, like, this is roughly, you know, the most straightforward way of passing messages between rollups without introducing additional assumptions on off-chain oracles or anything. Just using the L1. Now, the downside of this, of course, is that in order for Rollup B to read a message from Rollup A, it needs to wait for Rollup A to not only finalize its transactions by posting to Ethereum and waiting for Ethereum finality, which is about 12 to 15 minutes, but it needs to be able to trust that Merkle route, and so that requires waiting the settlement time of rollup A which could be multiple days if rollup A is an optimistic rollup. So this way of passing messages via the L1 takes a very long time. It can take multiple days. So cross-chain transactions, they have very high latency, long wait before a chain can read a message from another chain. The other thing that asynchronous message passing via the L1 doesn't achieve is it doesn't achieve this asset property for cross-chain transactions. So there's another way of passing messages, potentially faster. And so this is a slight change. What we're going to do here is we won't wait for verifying a message against a Merkle root, but rather the sequencers will just be allowed to fill the inboxes with messages that were allegedly written to the outboxes of the other chains, and just sort of optimistically accept them, process them, and only at settlement time will we do anything to check that the messages that were written to the outbox of the first chain are consistent with the messages that were written to the inbox of the second chain. So this requires a change in the way that rollups settle. It requires this coordinated settlement, or aggregated settlement, as some people call it. And this could, for example, be just implemented as a cross-check on the L1 between the Merkle roots of the two different mailboxes. Or we could involve some kind of aggregator that creates ZK proofs of the two different chains and actually proves the consistency of the mailboxes as well. Now, the advantage of this is that the rollups don't have to wait for multiple days in order to ingest a message from the other chain. Of course, if they're given an incorrect message, then they will experience... I mean, when they go to settle, it won't work. So it's sort of like when you create an invalid block for a ZK roll-up, and then the proof can't be created, and then you would have to go back to where you were before. It's not technically a reorg, but the full nodes could become confused for some period of time. But optimistically, you would just be able to make progress really fast, right? And you still have the security of the L1. Now, when you're passing messages this way, you're still not able to achieve ACID cross-chain transactions because, you know, let's say you were trying to use this in order to achieve some kind of atomic swap, you would send a message to another chain that you locked an asset, you would wait for a message back, you know, verifying some event on the other chain. In that interim time, you're in these locked intermediary states, that's observable, so you don't really have this ACID property. For this ACID property to hold, you need something called synchronous composability. Okay, so why are ACID cross-chain transactions so hard to achieve? Well, you need to be able to emulate multiple rounds of communication. You need to be able to do something, send a message to another chain, and wait for a response back. And that all needs to happen within one block. That can't happen across multiple blocks. There's also an inherent dependency on the global ordering of transactions across all chains of the individual transactions on those chains. If you're sending multiple rounds of communication, then the relative ordering of these different transactions on the different chains will have an impact on what happens. Now, of course, there's a naive solution, which is just to merge all chains into one, and that would certainly achieve this ACID property, right? That's a naive straw man. But the reason why this is hard to do in this, you know, is very much because of the constraint that we want to retain efficiency. We want to preserve horizontal scaling. So on its own, ACID is not hard to achieve. It's hard to achieve it in a way that preserves scalability. And so one way to sort of make this a bit more precise is to view this through the lens of collaborative snarks. Snarks, for those of you who aren't familiar with the term, are just the technical term for ZK proofs. ZK proofs, at least the ones that we use in the blockchain world, are succinct, non-interactive proofs of knowledge. Rollups don't even use the zero knowledge property, so it's just sort of a misnomer that we ended up calling them ZK proofs. But Snarks are the same things as ZK proofs. So there's this implicit, whenever you have chains interacting, there's this implicit unified virtual machine in which the cross-chain transactions, it's a tongue twister, take place. And so the goal is really to create some kind of single ZK proof of a state transition for a distributed system of virtual machines with this inter-process communication where we introduce one prover per virtual machine, and the total work done per prover should remain near constant as the number of interacting virtual machines grows. So that's sort of the goal of being able to preserve the scalability, the fact that the total work done per prover, per chain, remains near constant. It doesn't grow, you know, as linearly as the number of chains grows. And in other words, the total amount of work being done in the system is linear, and the number of provers is not quadratic. So we actually can apply generic solutions to this. There are generic ways of just having all the provers for the different chains collaborate on creating a distributed SNARK for the unified VM that, you know, is their composition. You can use SNARK recursion for this. There's other ways of doing it through distributed SNARK protocols, like something called distributed sum check, distributed FFTs. So, you know, it's not typically the way that we think about it. We think about provers being sort of their job is to just create proofs for their own roll-up, but maybe the goal should actually just be that the overall work should, you know, be horizontally scalable. But I'm going to present today sort of what you can be viewed as a special case of this, but it's a lot closer to the model in which rollups interoperate and act today. And it's just a simple extension of the asynchronous message mailbox design that I presented at the beginning. So we still have the outbox and inboxes on the two different chains, but the key difference here is that instead of chains writing to their outbox and then in the next block being able to read a bunch of messages that were populated to their inbox, ostensibly that should match the messages written to the outbox to the other chain in the previous block, that's how we did it before, there's going to be a coordinator that can just figure out, okay, these are the messages that this other chain is writing to its outbox, by simulating the execution, and I'm going to provide you with those messages. And so these two blocks are constructed at the very same time. Chains are really just verifying execution, they're not, they don't need to carry out the execution themselves, constructed at the very same time. Chains are really just verifying execution. They don't need to carry out the execution themselves. The execution is carried out by builders who are building the blocks, in this case a coordinator. This coordinator simulates the execution. So I can walk through an example. You can have a transaction on rollup A that basically borrows funds from some contract. It burns them. It writes a message to its outbox that they were burned. And then immediately reads a message from its inbox that something happened on the other side. A lot of things happened in the middle over there, but they just weren't observable to this chain. So it immediately reads that messages were then minted on the other side. In the meantime, what happened was on rollup B, there was a message that was provided in the inbox that said, oh, funds were burned on rollup A. It then did a bunch of things, maybe multiple swaps at desired prices, made some profit, and then burned the funds, wrote that message to its outbox. That message was provided by the coordinator to the inbox of rollup A, causing this transaction to complete. the refunds were returned. Now, if there was any inconsistency, if some message was written to the outbox B but that wasn't put in the inbox A, then that would be caught at settlement time. As we showed, when the roll-ups settle, all we need to do is make sure that the outboxes of chain A matches the inbox of chain B and vice versa. The outbox of chain B matches the inbox of chain A. So that provides you the intuition. We have a full protocol on this called Coordinated Inter-Rollup Communication. It's not fully general, but it covers most practical use cases of synchronous composability among independent chains, like flash loans, which I just showed the example of, It is not fully general, but it covers most practical use cases of synchronous composability among independent chains, like flash loans, which I just showed the example of, asset swaps, limit orders, basically anything that we can really think of. It would be interesting to see if people come up with use cases that are practical that aren't covered. It doesn't require any VM modifications to the chains. You just need to implement these contracts as mailboxes as contracts. And it enables parallel proving. So each L2 prover just independently proves its own state. It proves what the Merkle root of its mailbox is. And then there's an aggregator that creates a simple aggregated proof whose complexity is completely independent of the complexity of each chain. These mailboxes are implemented as contracts. They use authent are implemented as contracts. They use authenticated key value maps. And, you know, any contract can basically write to the app box or read from the inbox. But you index it by which contract wrote. So it doesn't allow contracts to sort of conflict with each other and overwrite each other. And then you have the settlement layer contract that basically just verifies the correctness of state updates from each roll-up and checks the mailbox consistency by verifying this aggregated proof. So this is what it looks like. We have this aggregator, just like before. It's exactly like the asynchronous setting, it's just that we have this coordinator, which could be, for example, a shared sequencer that figures out what messages are being communicated between the two chains, could be multiple rounds of messages, and provides those messages ahead of time, pre-populates the inboxes of the two different chains with the messages that they should be receiving over multiple rounds of communication. Now, one important variantant of roll-ups is that full nodes should always know the state. Once a sequencer posts a transaction ordering, full nodes should be able to immediately calculate the roll-up state. They shouldn't have to wait for L1 settlement. Waiting for L1 finality of the sequencer published blocks is generally sufficient. And if the sequencer is trusted not to change its mind about what it's going to post, then full nodes should be able to trust a pre-confirmation from the sequencer within seconds. Now, the problem is that this protocol circ sort of breaks that property unless it you know, if done naively. And the issue is that because the rollups are now interacting, the full nodes of rollup A who are ostensibly only executing for rollup A, they don't really know the state of rollup A until they can trust that the messages the coordinator provided are correct. And it won't really know that until settlement time. So how do we, yeah, how do we solve that issue? are correct and it won't really know that until settlement time. So how do we solve that issue? That's problem number one. Problem number two is that normally you can trust a sequencer for fast confirmations. Here this coordinator, which is going to be coordinating the mailbox constructions across many, many different chains, becomes a single point of failure. And so, you know, maybe the full nodes of Arbitrum can trust the Arbitrum centralized sequencer, and the Optimism full nodes can trust the Optimism sequencer, but it's hard to trust one sequencer for confirmations when multiple chains are interacting. The solution is to fold, one, make ZK-Proofs faster that can be communicated offline really fast, and two, use the fast confirmation layer. So a fast confirmation layer is basically a BFT consensus protocol that reaches finality faster than the L1 and ensures that whatever was finalized by the consensus protocol, you know, has to be what's eventually posted to the L1. Fast off-chain ZK proofs are interesting because the goal here is to optimize the end-to-end latency of proving. You know, and proving proof aggregation verification given the constraints on the bandwidth and compute power of each full node. And so it motivates different design constraints than when we're just trying to have ZK proofs optimized for L1 settlement. Because the bandwidth and compute requirements of L2 nodes could be different. And so we could consider using SNARKs with larger communication, but faster proofs, like Orion, Breakdown, BaseFold, Blaze, or a number of other systems. So anyways, this is what it looks like putting it all together. You have some shared sequencer that coordinates the mailbox construction. The blocks are sent to a confirmation layer. They're confirmed. Rollup A and Rollup B provers and create these proofs. And then you have some kind of aggregated settlement. And this is how you enable chains to either have very fast asynchronous communication or even synchronous communication that enables synchronous composability. So thank you very much, and I will go on to the questions. Good stuff, Ben. Very technical. I think we've got time for a few questions. So the first one that's on there is the coordinator of two roll-ups needs to be synced to both of them, right? In other words, he needs to be executing both rollups himself. That's correct. Okay. That was an easy one. Easy. And what happens if the message box says fork before settlement? Wouldn't the nodes be reading just one rollup, be lost until settlement? Which one is this? Oh, now it's number two. Okay. What happens if the message box is fork? Okay, social wants to be the shared player for all of us. I think I'm seeing different questions than you are. Oh, the second one. What happens if the message box is forked before settlement? So the message boxes don't fork before settlement. I mean, so the chains need to have something that is used for their, you know, as their sort of finality layer. You can, of course, wait for L1 finality on the blocks that were published. So you publish the blocks to the L1. That's pre-settlement time. Or if you have a fast confirmation layer, such as the one that Espresso Network provides, right, then you would be publishing those blocks to that fast confirmation layer and then you would ensure that whatever is posted at settlement time is consistent with that. Ultimately, you can define the rules or constraints of what constrains the roll-ups before settlement time, but at settlement time, you would be posting a collection of blocks for the different roll-ups that are consistent with each other in terms of these mailbox consistency checks and consistent with the rules of those roll-ups for what was finalized on different various layers before that settlement time. Okay, the next question. It voted up while it was up there. A little spicy. Espresso wants to be the shared layer for roll-ups but lacks credible neutrality. It voted up while it was up there, a little spicy. Yeah. Espresso wants to be the shared layer for roll-ups, but lacks credible neutrality. How keen is Espresso on jointly designing the shared layer with roll-ups? So, yeah. So Espresso has been designing this, you know, sort of confirmation layer, as we call it, which it doesn't do everything that I described today. It provides this fast confirmation layer that rollups can use. Today the Espresso network, in fact, is live on mainnet. And we have been building towards creating infrastructure that rollups can use to enhance their composability. And we've been doing it very much in collaboration and taking feedback from, you know, from roll-ups, just like DA layers, et cetera. Okay, the next one, something that I've seen when I was briefly working with roll-ups on the DevOps side, is that how can cross-chain message passing happen if roll-ups have different latencies and hardly can be viewed as synchronized, especially with AMMs protocols being strictly arbitrage and asynchronous? It's like some that post once a day and some that post once an hour. Right, so how can cross-chain message passing happen if rollups have different latencies and hardly can be viewed as synchronized? So if rollups... So first of all, I presented two different kinds of modes of communication. So there's asynchronous communication and synchronous communication. If the roll-ups is not about, it's not actually, it's not the latencies that matters. It's the block times of the roll-ups. So the block times are different, and you can still communicate asynchronously. If the block times are not synced, then you can't communicate synchronously. So you would have to synchronize the block times, but you can also have different size blocks on the different rollups.",
- "eventId": "devcon-7",
- "slot_start": 1731472800000,
- "slot_end": 1731473400000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1WNKyHeXOwkXmvaf0GIGfAtO5R7MQYyUbdRwxgk23ZzQ",
- "resources_slides": null,
"speakers": [
- "rim-rakhimov"
- ]
+ "amy-proal"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731573300000,
+ "slot_end": 1731574200000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/17eofu9OtkjONNHPpAdEmPg8MIz7E8ahPAxLdRwJsfNY"
},
"vector": [
- 0,
- 0,
0,
6,
0,
@@ -831980,6 +830202,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -832055,7 +830278,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -832285,7 +830507,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -832446,7 +830667,7 @@
0,
0,
0,
- 2,
+ 0,
0,
0,
0,
@@ -832592,10 +830813,10 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -832608,46 +830829,31 @@
},
{
"session": {
- "id": "verkle-integration-in-reth",
- "sourceId": "T8LKTM",
- "title": "Verkle integration in reth",
- "description": "This talk concerns the presentation of EPF Project: Verkle integration in reth.\r\nThe project comprised of replacing the current state-commitment structure in reth with verkle tries and other modifications for statelessness, including implementing EIPs such as EIP-4762: Statelessness gas cost changes (to REVM), EIP-6800: Ethereum State using a unified verkle trie, EIP-7709: Read BLOCKHASH from storage and update cost, and passing the associated execution-spec-test vectors designed for these EIPs.",
- "track": "[CLS] EPF Day",
+ "id": "visions-of-a-viable-dacc-biosafety-strategy",
+ "sourceId": "7VDGQM",
+ "title": "Visions of a Viable d/acc Biosafety Strategy",
+ "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "EPF",
- "Core Protocol",
- "Cryptography",
- "Verkle trees"
- ],
- "keywords": [
- "Stateless clients",
- "Verge"
- ],
- "duration": 871,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "4c3add1def5321ff44e6a128ca79299c6b8f9c3c4c274d2d79412d0bcf266853",
- "sources_youtubeId": "b7JdDe2kW98",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731472200000,
- "slot_end": 1731473100000,
- "slot_roomId": "breakout-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1Uq2DzZBnDwPSfrV2xqfm-mlie2DOZZKEwi0Kk44YlQI",
- "resources_slides": null,
"speakers": [
- "aditya-gupta"
- ]
+ "vitalik-buterin"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731567600000,
+ "slot_end": 1731568200000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1yGQBHJnRzdZfi9mog9ipmc0zYrZB2nzXpEG4mGwCGko"
},
"vector": [
+ 0,
+ 6,
0,
0,
0,
@@ -832663,7 +830869,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -832836,6 +831041,26 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -833356,7 +831581,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -833413,13 +831637,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -833593,7 +831815,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -833704,25 +831925,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -833964,8 +832166,6 @@
2,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -833978,42 +832178,53 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "viruses-and-chronic-aging-building-a-research-community",
- "sourceId": "FX8UQF",
- "title": "Viruses and Chronic Aging: Building a Research Community",
- "description": "Did you know that mitochondrial dysfunction, inflammation, and cognitive decline are directly accelerated by viruses? In fact, the viruses that infect us over a lifetime are technically not even alive, and therefore must “hack” our human cellular metabolism machinery to do anything at all. This talk will overview the first-ever global collaborative network studying & treating chronic viruses as drivers of aging, including how certain lifespan-promoting drugs may help combat viral activity.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "id": "visual-code-of-cypherpunk-and-lessons-from-subcultural-aesthetics-we-should-remember-on-the-road-to-mass-adoption",
+ "sourceId": "ZAYEXK",
+ "title": "Visual code of cypherpunk, and lessons from subcultural aesthetics we should remember on the road to mass adoption",
+ "description": "I want to take builders on the turbulent ride through how subcultural and social movements used their visual codes when spreading globally, and what design tasks are still ahead of us on the way to making Ethereum cypherpunk again and onboarding the next billion users to Web3 at the same time.\r\n\r\nThis ride will include three stops:\r\n1. waving one's emotional state into the collective identity\r\n2. using shared aesthetics as a signal of belonging\r\n3. coordinating a collective design process.",
+ "track": "Cypherpunk & Privacy",
"type": "Lightning Talk",
- "expertise": "Intermediate",
+ "expertise": "Beginner",
"audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "culture",
+ "aesthetics",
+ "communication"
+ ],
+ "tags": [
+ "Coordination",
+ "Identity",
+ "Design",
+ "communication",
+ "Coordination",
+ "Design",
+ "Identity"
+ ],
"language": "en",
"speakers": [
- "amy-proal"
+ "ira-nezhynska"
],
"eventId": "devcon-7",
- "slot_start": 1731573300000,
- "slot_end": 1731574200000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/17eofu9OtkjONNHPpAdEmPg8MIz7E8ahPAxLdRwJsfNY"
+ "slot_start": 1731495000000,
+ "slot_end": 1731495600000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1JfZtSjos8JrMCOBp9B9xIaU5dMAfVMzayGYW7eA5F7Q"
},
"vector": [
- 0,
- 6,
- 0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -834806,6 +833017,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -834899,6 +833111,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -834910,6 +833123,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -835014,9 +833228,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -835326,8 +833538,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
@@ -835341,39 +833551,44 @@
},
{
"session": {
- "id": "visions-of-a-viable-dacc-biosafety-strategy",
- "sourceId": "7VDGQM",
- "title": "Visions of a Viable d/acc Biosafety Strategy",
- "description": "A one-day summit focusing on the theme of d/acc: emphasizing the values of decentralization, democracy, differential accelerated progress, and defensive tech including crypto security, public epistemics, bio defense, neurotech/longevity, decentralized ai and physical resilience.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
- "type": "Lightning Talk",
- "expertise": "",
- "audience": "Engineering",
+ "id": "vlsmsanalyzing-faulty-distributed-systems",
+ "sourceId": "AKRLKH",
+ "title": "VLSMs—analyzing faulty distributed systems",
+ "description": "Validating Labeled State transition and Message production systems (VLSMs) provide a general approach to modeling and verifying faulty distributed systems. With formal definitions of validation and equivocation, we are able to prove that for systems of validators, the impact of Byzantine components is indistinguishable from the effect of the introduction of corresponding equivocating components. All of the results presented in this talk have been formalized and checked in the Coq proof assistant",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Correct-by-construction"
+ ],
+ "tags": [
+ "Consensus",
+ "Distributed validator technology",
+ "Formal Verification",
+ "correct-by-construction",
+ "Consensus",
+ "Distributed validator technology",
+ "Formal Verification"
+ ],
"language": "en",
"speakers": [
- "vitalik-buterin"
+ "vlad-zamfir"
],
"eventId": "devcon-7",
- "slot_start": 1731567600000,
- "slot_end": 1731568200000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1yGQBHJnRzdZfi9mog9ipmc0zYrZB2nzXpEG4mGwCGko"
+ "slot_start": 1731552300000,
+ "slot_end": 1731554100000,
+ "slot_roomId": "classroom-d",
+ "resources_presentation": "https://docs.google.com/presentation/d/1neM1-qHBPiHQ47mw5gGhxKmdlAYMtpZujIccA88zZM8"
},
"vector": [
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -835554,7 +833769,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -836078,6 +834292,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -836123,6 +834338,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -836314,6 +834530,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -836579,6 +834796,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -836654,6 +834872,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -836680,7 +834899,6 @@
0,
2,
0,
- 0,
2,
0,
0,
@@ -836693,45 +834911,43 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "visual-code-of-cypherpunk-and-lessons-from-subcultural-aesthetics-we-should-remember-on-the-road-to-mass-adoption",
- "sourceId": "ZAYEXK",
- "title": "Visual code of cypherpunk, and lessons from subcultural aesthetics we should remember on the road to mass adoption",
- "description": "I want to take builders on the turbulent ride through how subcultural and social movements used their visual codes when spreading globally, and what design tasks are still ahead of us on the way to making Ethereum cypherpunk again and onboarding the next billion users to Web3 at the same time.\r\n\r\nThis ride will include three stops:\r\n1. waving one's emotional state into the collective identity\r\n2. using shared aesthetics as a signal of belonging\r\n3. coordinating a collective design process.",
+ "id": "voices-of-tech-and-open-source-movement-across-asia",
+ "sourceId": "QCPSDK",
+ "title": "Voices of Tech & Open Source Movement Across Asia",
+ "description": "This panel discussion features individuals from the open source communities, developer and user groups across Asia. These figures span different decades and have witnessed various phases of the tech movement, including the rise of open source, in their respective countries. Some have been pioneers since the early days, while others have emerged as key players through recent college engagements and grassroots initiatives.",
"track": "Cypherpunk & Privacy",
- "type": "Lightning Talk",
+ "type": "Panel",
"expertise": "Beginner",
- "audience": "Community",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "culture",
- "aesthetics",
- "communication"
+ "FOSS",
+ "Regional",
+ "Insights"
],
"tags": [
- "Coordination",
- "Identity",
- "Design",
- "communication",
- "Coordination",
- "Design",
- "Identity"
+ "FOSS",
+ "regional",
+ "insights"
],
"language": "en",
"speakers": [
- "ira-nezhynska"
+ "hong-phuc-dang",
+ "mario-behling",
+ "brianna-chang",
+ "mishari-muqbil"
],
"eventId": "devcon-7",
- "slot_start": 1731495000000,
- "slot_end": 1731495600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1JfZtSjos8JrMCOBp9B9xIaU5dMAfVMzayGYW7eA5F7Q"
+ "slot_start": 1731468600000,
+ "slot_end": 1731472200000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1ADQtojPz5zGpvoa8L2aH0vcyddEYsowQH6-jcNkUIMU"
},
"vector": [
0,
@@ -837443,7 +835659,9 @@
0,
0,
0,
- 0,
+ 6,
+ 6,
+ 6,
6,
0,
0,
@@ -837535,11 +835753,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -837629,7 +835842,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -837641,7 +835853,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -837747,7 +835958,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -837822,6 +836032,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -838028,6 +836239,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -838051,12 +836264,12 @@
0,
2,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -838069,44 +836282,45 @@
},
{
"session": {
- "id": "vlsmsanalyzing-faulty-distributed-systems",
- "sourceId": "AKRLKH",
- "title": "VLSMs—analyzing faulty distributed systems",
- "description": "Validating Labeled State transition and Message production systems (VLSMs) provide a general approach to modeling and verifying faulty distributed systems. With formal definitions of validation and equivocation, we are able to prove that for systems of validators, the impact of Byzantine components is indistinguishable from the effect of the introduction of corresponding equivocating components. All of the results presented in this talk have been formalized and checked in the Coq proof assistant",
- "track": "Core Protocol",
+ "id": "voting-with-time-commitment",
+ "sourceId": "7V7QNK",
+ "title": "Voting with time commitment",
+ "description": "Token-based voting mechanisms employed by DAOs can encounter three potential problems: plutocracy, Sybil attacks and vote buying. If one were to design a voting mechanism from scratch, how does one ensure that these issues are addressed adequately down the road? This talk aims to provide some intuition for the trade-offs faced when tackling these problems in general, and the role of time commitment in alleviating these issues, in particular.",
+ "track": "Cryptoeconomics",
"type": "Talk",
- "expertise": "Expert",
- "audience": "Research",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Correct-by-construction"
+ "Voting"
],
"tags": [
- "Consensus",
- "Distributed validator technology",
- "Formal Verification",
- "correct-by-construction",
- "Consensus",
- "Distributed validator technology",
- "Formal Verification"
+ "Governance",
+ "Mechanism design",
+ "voting",
+ "Governance",
+ "Mechanism design"
],
"language": "en",
"speakers": [
- "vlad-zamfir"
+ "vijay-mohan"
],
"eventId": "devcon-7",
- "slot_start": 1731552300000,
- "slot_end": 1731554100000,
- "slot_roomId": "classroom-d",
- "resources_presentation": "https://docs.google.com/presentation/d/1neM1-qHBPiHQ47mw5gGhxKmdlAYMtpZujIccA88zZM8"
+ "slot_start": 1731489600000,
+ "slot_end": 1731491400000,
+ "slot_roomId": "stage-1",
+ "sources_streamethId": "673476f19dbb7a90e139f8dc",
+ "resources_presentation": "https://docs.google.com/presentation/d/1P434UTSmq4E68DmH8ddDjupGoA0DAAfW5KIZ-umwqaM"
},
"vector": [
+ 0,
+ 0,
+ 6,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -838856,10 +837070,10 @@
0,
0,
0,
+ 6,
0,
0,
0,
- 6,
0,
0,
0,
@@ -838945,6 +837159,15 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -839051,7 +837274,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -839201,6 +837423,22 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -839320,13 +837558,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -839397,30 +837628,8 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
2,
0,
- 2,
0,
0,
0,
@@ -839437,46 +837646,42 @@
},
{
"session": {
- "id": "voices-of-tech-and-open-source-movement-across-asia",
- "sourceId": "QCPSDK",
- "title": "Voices of Tech & Open Source Movement Across Asia",
- "description": "This panel discussion features individuals from the open source communities, developer and user groups across Asia. These figures span different decades and have witnessed various phases of the tech movement, including the rise of open source, in their respective countries. Some have been pioneers since the early days, while others have emerged as key players through recent college engagements and grassroots initiatives.",
- "track": "Cypherpunk & Privacy",
- "type": "Panel",
+ "id": "wallet-infra-improvements-and-building-apps-for-the-next-generation",
+ "sourceId": "RQAAFS",
+ "title": "Wallet Infra Improvements, and Building Apps for the Next Generation",
+ "description": "In this talk I go over infrastructure innovations that are happening in the space right now, how they’re going to be how we bring the next wave of users into crypto, and why right now is the best time to build a consumer app in this space.",
+ "track": "Usability",
+ "type": "Lightning Talk",
"expertise": "Beginner",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "FOSS",
- "Regional",
- "Insights"
+ "wallet",
+ "dapps",
+ ""
],
"tags": [
- "FOSS",
- "regional",
- "insights"
+ "Accessibility",
+ "Account Abstraction",
+ "Architecture",
+ "Frameworks",
+ "Gas",
+ "Intents",
+ "Payment",
+ "UI/UX"
],
"language": "en",
"speakers": [
- "hong-phuc-dang",
- "mario-behling",
- "brianna-chang",
- "mishari-muqbil"
+ "medha-kothari"
],
"eventId": "devcon-7",
- "slot_start": 1731468600000,
- "slot_end": 1731472200000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1ADQtojPz5zGpvoa8L2aH0vcyddEYsowQH6-jcNkUIMU"
+ "slot_start": 1731558600000,
+ "slot_end": 1731559200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1eJwIYkq9W94rsLobC0VKWwi7AVWG4wvUfj48LQs1f8k"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
0,
0,
0,
@@ -839485,6 +837690,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -840183,10 +838389,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
0,
0,
0,
@@ -840194,6 +838396,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -840279,13 +838482,18 @@
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
0,
0,
0,
+ 2,
+ 2,
0,
+ 2,
0,
0,
0,
@@ -840328,6 +838536,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -840363,6 +838572,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -840448,6 +838658,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -840557,7 +838768,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -840763,8 +838973,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -840806,48 +839014,53 @@
},
{
"session": {
- "id": "voting-with-time-commitment",
- "sourceId": "7V7QNK",
- "title": "Voting with time commitment",
- "description": "Token-based voting mechanisms employed by DAOs can encounter three potential problems: plutocracy, Sybil attacks and vote buying. If one were to design a voting mechanism from scratch, how does one ensure that these issues are addressed adequately down the road? This talk aims to provide some intuition for the trade-offs faced when tackling these problems in general, and the role of time commitment in alleviating these issues, in particular.",
- "track": "Cryptoeconomics",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "id": "wallet-ux-panel",
+ "sourceId": "9HACGK",
+ "title": "Wallet UX Panel",
+ "description": "Wallets are here to provide great user experience with robust security. \r\nBringing the top wallet providers (Fireblocks, Safe, Metamask, Coinbase and WalletConnect/Reown) to talk about how Ethereum user UX evolved and how we can make it much better.",
+ "track": "Usability",
+ "type": "Panel",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Voting"
+ "Wallets",
+ "User Experience",
+ "Standards"
],
"tags": [
- "Governance",
- "Mechanism design",
- "voting",
- "Governance",
- "Mechanism design"
+ "Coordination",
+ "Custody",
+ "Account Abstraction",
+ "standards",
+ "Account Abstraction",
+ "Coordination",
+ "Custody"
],
"language": "en",
"speakers": [
- "vijay-mohan"
+ "lukas-schor",
+ "derek-rein",
+ "arik-galansky",
+ "adam-ceresko"
],
"eventId": "devcon-7",
- "slot_start": 1731489600000,
- "slot_end": 1731491400000,
- "slot_roomId": "stage-1",
- "sources_streamethId": "673476f19dbb7a90e139f8dc",
- "resources_presentation": "https://docs.google.com/presentation/d/1P434UTSmq4E68DmH8ddDjupGoA0DAAfW5KIZ-umwqaM"
+ "slot_start": 1731472200000,
+ "slot_end": 1731475800000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1qtrl6r-TYlWqtL69dNckKj8GBF_OtG2FNSwchnfA6ew"
},
"vector": [
0,
0,
- 6,
- 0,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -841555,6 +839768,9 @@
0,
0,
6,
+ 6,
+ 6,
+ 6,
0,
0,
0,
@@ -841597,11 +839813,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -841641,6 +839852,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -841686,7 +839898,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -841735,6 +839946,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -841744,6 +839956,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -841951,7 +840164,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -842065,6 +840277,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -842155,12 +840368,10 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -842173,40 +840384,25 @@
},
{
"session": {
- "id": "wallet-infra-improvements-and-building-apps-for-the-next-generation",
- "sourceId": "RQAAFS",
- "title": "Wallet Infra Improvements, and Building Apps for the Next Generation",
- "description": "In this talk I go over infrastructure innovations that are happening in the space right now, how they’re going to be how we bring the next wave of users into crypto, and why right now is the best time to build a consumer app in this space.",
- "track": "Usability",
- "type": "Lightning Talk",
- "expertise": "Beginner",
+ "id": "warren-winter",
+ "sourceId": "9PWLDW",
+ "title": "Warren Winter",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "wallet",
- "dapps",
- ""
- ],
- "tags": [
- "Accessibility",
- "Account Abstraction",
- "Architecture",
- "Frameworks",
- "Gas",
- "Intents",
- "Payment",
- "UI/UX"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "medha-kothari"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731558600000,
- "slot_end": 1731559200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1eJwIYkq9W94rsLobC0VKWwi7AVWG4wvUfj48LQs1f8k"
+ "slot_start": 1731577500000,
+ "slot_end": 1731580200000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1KC8s2MGqxozkSjf4Ogbdu9s8XFZLZgkj32ySca-LrnQ"
},
"vector": [
0,
@@ -842217,6 +840413,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -842926,7 +841123,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -843012,18 +841208,13 @@
0,
0,
0,
- 2,
0,
0,
0,
- 2,
0,
0,
0,
- 2,
- 2,
0,
- 2,
0,
0,
0,
@@ -843066,7 +841257,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -843102,7 +841292,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -843189,47 +841378,50 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -843526,6 +841718,7 @@
0,
2,
0,
+ 0,
2,
0,
0,
@@ -843544,42 +841737,25 @@
},
{
"session": {
- "id": "wallet-ux-panel",
- "sourceId": "9HACGK",
- "title": "Wallet UX Panel",
- "description": "Wallets are here to provide great user experience with robust security. \r\nBringing the top wallet providers (Fireblocks, Safe, Metamask, Coinbase and WalletConnect/Reown) to talk about how Ethereum user UX evolved and how we can make it much better.",
- "track": "Usability",
- "type": "Panel",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "web3-poetry-day-1",
+ "sourceId": "VDMFMR",
+ "title": "Web3 Poetry - Day 1",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Wallets",
- "User Experience",
- "Standards"
- ],
- "tags": [
- "Coordination",
- "Custody",
- "Account Abstraction",
- "standards",
- "Account Abstraction",
- "Coordination",
- "Custody"
- ],
+ "keywords": [],
+ "tags": [],
"language": "en",
- "speakers": [
- "lukas-schor",
- "derek-rein",
- "arik-galansky",
- "adam-ceresko"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731472200000,
- "slot_end": 1731475800000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1qtrl6r-TYlWqtL69dNckKj8GBF_OtG2FNSwchnfA6ew"
+ "slot_start": 1731398400000,
+ "slot_end": 1731402000000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1YlWqriBn80NWKxkgkyOqcJWz0Dtul50_teTrfXcFHJA"
},
"vector": [
0,
@@ -843590,6 +841766,7 @@
0,
0,
0,
+ 0,
6,
0,
0,
@@ -844300,10 +842477,6 @@
0,
0,
0,
- 6,
- 6,
- 6,
- 6,
0,
0,
0,
@@ -844385,7 +842558,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -844479,7 +842651,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -844489,7 +842660,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -844813,7 +842983,9 @@
0,
0,
0,
- 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -844900,11 +843072,12 @@
2,
0,
0,
+ 2,
+ 0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -844917,9 +843090,9 @@
},
{
"session": {
- "id": "warren-winter",
- "sourceId": "9PWLDW",
- "title": "Warren Winter",
+ "id": "web3-poetry-day-3",
+ "sourceId": "GN8LTB",
+ "title": "Web3 Poetry - Day 3",
"description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
"track": "Entertainment",
"type": "Music",
@@ -844932,10 +843105,10 @@
"language": "en",
"speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731577500000,
- "slot_end": 1731580200000,
+ "slot_start": 1731571200000,
+ "slot_end": 1731574800000,
"slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1KC8s2MGqxozkSjf4Ogbdu9s8XFZLZgkj32ySca-LrnQ"
+ "resources_presentation": "https://docs.google.com/presentation/d/16EbmLxT3rCfmlW9Mc5CErRzSrp05fgvj7stvb6H3iaY"
},
"vector": [
0,
@@ -846249,9 +844422,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -846273,9 +844443,9 @@
},
{
"session": {
- "id": "web3-poetry-day-1",
- "sourceId": "VDMFMR",
- "title": "Web3 Poetry - Day 1",
+ "id": "web3-poetry-jam",
+ "sourceId": "V79DXK",
+ "title": "Web3 Poetry Jam",
"description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
"track": "Entertainment",
"type": "Music",
@@ -846288,10 +844458,10 @@
"language": "en",
"speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731398400000,
- "slot_end": 1731402000000,
+ "slot_start": 1731484800000,
+ "slot_end": 1731486600000,
"slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1YlWqriBn80NWKxkgkyOqcJWz0Dtul50_teTrfXcFHJA"
+ "resources_presentation": "https://docs.google.com/presentation/d/1XSH7eVjgLTTnQVBK8jxg0l8v8m1RayeW3qpih1FAFHY"
},
"vector": [
0,
@@ -847605,9 +845775,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -847629,36 +845796,36 @@
},
{
"session": {
- "id": "web3-poetry-day-3",
- "sourceId": "GN8LTB",
- "title": "Web3 Poetry - Day 3",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
+ "id": "web3-security-is-embarrasing",
+ "sourceId": "VNFNDM",
+ "title": "Web3 Security is Embarrasing",
+ "description": "The explosive growth of Web3 has brought about innovation, decentralization, and financial opportunity. But let’s be honest—Web3 security is a disaster. In this talk, we’ll confront embarrassing truths: drainer attacks, weak wallet protections, and overlooked vulnerabilities. But we won’t stop there; I’ll share practical fixes to protect users and show how Web3 developers can raise the bar. If we want Web3 to thrive, we have to stop attackers beating us with low-effort attacks. We can do better!",
+ "track": "Security",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "phishing",
+ "protection"
+ ],
+ "tags": [
+ "Security",
+ "Sustainability",
+ "User Experience"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "andrew-macpherson"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731571200000,
+ "slot_start": 1731573000000,
"slot_end": 1731574800000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/16EbmLxT3rCfmlW9Mc5CErRzSrp05fgvj7stvb6H3iaY"
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1lEsNi0su_iRPEMbDkw-4CNthY3CMQvM_6ClpF3sBGNM"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
6,
0,
0,
@@ -848378,6 +846545,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -848406,6 +846575,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -848421,6 +846591,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -848753,6 +846924,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -848967,6 +847139,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -848985,25 +847158,42 @@
},
{
"session": {
- "id": "web3-poetry-jam",
- "sourceId": "V79DXK",
- "title": "Web3 Poetry Jam",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
- "audience": "Engineering",
- "featured": false,
+ "id": "web3-user-research-101",
+ "sourceId": "7YZGVW",
+ "title": "Web3 User Research 101",
+ "description": "Everything you’ve wanted to know about talking to users in web3 and were too afraid to ask! This workshop will give participants a crash course in user research and UX first principles, then guide them through the process of conducting a research project from start to finish - with a focus on web3 users specifically.",
+ "track": "Usability",
+ "type": "Workshop",
+ "expertise": "Beginner",
+ "audience": "Design",
+ "featured": true,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "101"
+ ],
+ "tags": [
+ "Best Practices",
+ "User Experience",
+ "UI/UX",
+ "User Research",
+ "Design Thinking",
+ "101",
+ "Best Practices",
+ "Design Thinking",
+ "UI/UX",
+ "User Experience",
+ "User Research"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "mindy-harrell",
+ "kristina-mayman"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731484800000,
- "slot_end": 1731486600000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1XSH7eVjgLTTnQVBK8jxg0l8v8m1RayeW3qpih1FAFHY"
+ "slot_start": 1731398400000,
+ "slot_end": 1731405600000,
+ "slot_roomId": "classroom-c",
+ "resources_presentation": "https://docs.google.com/presentation/d/1WDegVtKo7rojZIBJT9EVkbEcih7LrcH0QIwcJFOGr6Y"
},
"vector": [
0,
@@ -849014,7 +847204,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -849727,6 +847916,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -849770,6 +847961,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -849784,6 +847976,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -849811,6 +848004,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -849838,6 +848032,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -849894,6 +848089,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -850291,6 +848487,12 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -850306,23 +848508,6 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
2,
0,
0,
@@ -850336,52 +848521,64 @@
0,
0,
0,
+ 2,
+ 0,
0
]
},
{
"session": {
- "id": "web3-security-is-embarrasing",
- "sourceId": "VNFNDM",
- "title": "Web3 Security is Embarrasing",
- "description": "The explosive growth of Web3 has brought about innovation, decentralization, and financial opportunity. But let’s be honest—Web3 security is a disaster. In this talk, we’ll confront embarrassing truths: drainer attacks, weak wallet protections, and overlooked vulnerabilities. But we won’t stop there; I’ll share practical fixes to protect users and show how Web3 developers can raise the bar. If we want Web3 to thrive, we have to stop attackers beating us with low-effort attacks. We can do better!",
- "track": "Security",
+ "id": "wen-p2p-electronic-cash-system",
+ "sourceId": "ZFX3ZF",
+ "title": "Wen p2p Electronic Cash System?",
+ "description": "16 years have passed since Bitcoin whitepaper came out. Bitcoin was created as cypherpunk cash replacement. Cash means easy payments. But bitcoin found its PMF as 'digital gold', not as 'digital cash'. What happened to cash? What needs to happen for mass adoption of crypto payments?\r\nWe will go through the history of failed attempts. We'll end up with a hopeful analysis of why it's different in 2024 (spoiler alert: stablecoin adoption, cheap L2s, AA).",
+ "track": "Real World Ethereum",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "phishing",
- "protection"
- ],
"tags": [
- "Security",
- "Sustainability",
- "User Experience"
+ "Conviction",
+ "Payment",
+ "Account Abstraction",
+ "stablecoin",
+ "Account Abstraction",
+ "Conviction",
+ "Payment"
],
- "language": "en",
- "speakers": [
- "andrew-macpherson"
+ "keywords": [
+ "payments",
+ "cash",
+ "stablecoins"
],
+ "duration": 1549,
+ "language": "en",
+ "sources_swarmHash": "63b3f30cc56be0d58d80b8295e68bf9bdc088a286e0e5c0e86738ee20d1e2e1c",
+ "sources_youtubeId": "7JFFfcT1yzI",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673321cc3a168eb53554b6fe.vtt",
+ "transcript_text": " Hello. Hello. Cool. Who knows in which year the peer-to-peer electronic cash system paper came out? Anyone else? I'm sure you know. Just three people? Four people? Okay, which year was it? 2008, right? So we're still waiting for that peer-to-peer electronic cash. I think it's fair to say that we've not taken over the peer-to-peer payments world. Bitcoin has definitely found PMF product market fit with store of value. And I don't want to argue that there are no payments on Bitcoin. But clearly, the last payments you've made to come here, maybe with your Grab or Bolt or Uber were probably not Bitcoin or on-chain payments at all. Just to show how ancient this paper is, this is 2008, right? So in 2008, GTA 4 came out. That's how long ago this was. The iPhone just came out a year earlier. People dressed like this. I think it's cool, but also very, very ancient. Bitcoin was largely, well, came out right in time as a perfect reaction to the financial crisis of 2007-2008. This is how long ago it was. a perfect reaction to the financial crisis of 2007-8. This is how long ago it was. I think we all here know what peer-to-peer means, but let's briefly talk about the cash part, because I think it's very easy to think of cash as payments. But payments are not exactly cash. I would say that cash payments are a subset of all payments. And usually when we talk about payments, we talk about something that's much, much more complicated. So last time you ordered your Grab to get here, you made probably a credit card payment. With that there was a very big bundle of services that enabled things like chargebacks, maybe you were using a credit card and definitely there are some points and rewards so I'm still waiting for the visa and MasterCard airdrop. But I would just want to talk about the simplest of payments like this very raw payment which just goes payer to payee without all of these bundled services. So this is what we usually mean by cash payment, right? Like if I give 100 baht to a taxi driver, there's no way to charge back unless I hunt him down somehow. There are also no points and there's definitely not a credit system. So for today, I'd briefly like to talk about why we haven't taken over the world yet and what's needed to take over the world with on-chain payments. So I'll give a mini intro about myself and then we'll go through a mini history just to honor our ancestors. And then I'll talk through five narratives that were popular, or that are popular, to answer, like, this is the blocker. Like, we can't have payments because of, I don't know, scalability, let's say, right? So these will be the five Topics that we'll analyze So about me. I'm the peanut brain at peanut protocol. You can look me up Here and also DM me here So, let's go and honor our ancestors I think I think it's really important to realize the first wave of blockchains and categorize these very briefly. So we had Bitcoin, which I already mentioned, and then we had a bunch of payments projects that were strictly about this cash element, strictly about making payments happen. So I think Litecoin fits that category very well, and Dash definitely does. Stellar, I would say, too. Then we have private payments, Monero and Zcash. The only ones with smart contracts are Nex and Ethereum, by the way. So despite all of these huge ecosystems, well, some of them huge ecosystems, we haven't yet moved cash or payments on-chain. Despite all of these huge ecosystems, well, some of them huge ecosystems, we haven't yet moved cash or payments on-chain. So when I was prepping for this talk, I had the honor to talk to some of these ancestors and people who are working on these very ancient projects. And I asked them, like, how are you going about trying to bootstrap your payment network? And one of the guys I talked to, he was running a campaign in 2017 trying to convince parking garages and, like, very local shops in one local city in the US to adopt their coin as one of the payment methods. As you might guess, it's quite a hopeless endeavor endeavor because you not only have to convince the garages, but also you have to convince all the drivers to adopt your thing in an ecosystem where there is the dollar already and people are used to coins and dollar notes. So what's the advantage of bootstrapping that one token, one chain thing? I think quite similarly, we have... Who's been at ECC this year? Nice. Cool. You might have seen the payments cafe by base. They were selling cappuccinos where you could just take your Coinbase wallet and just make a payment for a cappuccino. And there I wondered, well, isn't it the same case? What's my reason to switch over from that? Like opening up my wallet and so on when I'm so used to just tapping my card, right? Especially that was just USDC on base with which you could pay. So here are the candidates. One common narrative will be scalability. So we need fast and cheap for transactions I'll kind of argue against that then another one is privacy I think highly important in a world where we have full adoption and most payments happen On chain, but I will also argue that we can have a world where settlement happens on chain butts And stuff is still reasonably private. Then another argument that is very common is, well, payments are not on chain yet, or haven't captured a whole payments market in TratFi because stablecoins are relatively new. I'll also argue against that. And then finally, for the 4337 mafia, one common argument is, hey, we need better account management. We have to have account abstraction, all these nice UX improvements. I will also say, well, that's not the main blocker here. And then finally, we'll go into the interrupt thesis. So let's start. I think this is a very common thing, especially in the early days of blockchains. This was a very, very common thing to hear when people were pitching L1s, but also still L2s, right? So the pitch goes something like this. In order to compete with TradFi payments, we have to be similarly cheap and fast. we're pitching L1s, but also still L2s, right? So the pitch goes something like this. In order to compete with TradFi payments, we have to be similarly cheap and fast. So Visa has 24,000 TPS, and my blockchain is so much faster. It has 69,000 TPS, right? I think, again, this kind of, it's a bad comparison because you're comparing these very raw payments of just transferring value from A to B with Visa, which is this very, very complex, very bundled payment solution. And then also, perhaps more importantly for the argument here, is there should be a subset of payments where this doesn't matter right so if i do a one million dollar transaction and there are hundreds of thousands of these happening every day or millions maybe even well definitely millions then it shouldn't matter whether i'm you know using bitcoin um which is slow and relatively expensive. But by the way, what do you think, what are current Bitcoin fees today? If I want to send $1 million to another country, what's the fee on Bitcoin in dollars? Any guesses? Yeah, $1. Yeah, that's not much. You can't do that in Tratva. You can't send $1 million to another country with one buck. You can't do that. Not in that order of magnitude, right? So clearly there should be some subset of payments where it would be more efficient to already use Bitcoin, something as simple as Bitcoin, as the kind of international settlement thing. This is especially true for rare international pairs where normally you would be doing many hops between banks, so the way a TradFi international payment works is you're sending it kind of they're exchanging these IOUs and they have these very custom agreements between each other to trust each other with these IOUs. So when you're sending, let's say, money from Armenia to Chile, it might very well be the case that this payment is going to do five or six hops across the world. So first to a more local bank, and then to another one, maybe then to some US bank, and then finally to some Latin bank, and then finally to Chile. In the meantime, you don't know where the payment is and the fees you don't know how much each intermediary is going to collect. So already this should be more, even with Bitcoin, something as primitive as Bitcoin, like V1 of blockchains, it should be more efficient. But guess what? Here's my startup idea. Why don't we do a TransferWise but with Bitcoin rails? So the way TransferWise works is you have these bank accounts in different countries, and then they kind of just internally settle the payment. So they front it for you. They receive it in one country, then they front it to you in the other country. Well, here's the problem. For that to happen, you would need two banks to agree not to ban you for your Bitcoin payments. So if you can convince two banks not to ban you because you're not fitting their AML requirements or they don't know what you're doing or they're just scared of Bitcoin or they think it's like some shady thing, then you might as well just have a normal, very classical IOU-type contract with these guys to just do a normal settlement. So if you've identified this pair where there's a lot of sudden trade happening, and it's not been captured yet, let's say, I don't know, Chileans suddenly get obsessed about Ethiopian coffee, if suddenly there's a lot of trade happening, immediately there will be someone who will try to capture those flows to avoid all these inefficiencies with these hops, right? And you can do so with IOUs for these large transactions. So this very convincing narrative, like when you hear it for the first time, oh yeah, sure, let's use crypto rails just for the international part, is actually maybe not as strong for these larger B2B transactions, especially when it comes to global supply chains. Cool. Another narrative, privacy. Well, we can't penetrate the whole market unless we have privacy. Obviously, if I go somewhere and I buy my coffee, I don't want to broadcast that to literally the entire world that I just bought a pumpkin spice latte. That's extremely embarrassing, and I don't want other people to know. I think, well, again, that does not much for the just Rails thesis, because you could have some kind of company that wraps Monero or Zcash or some other solution and makes it into a nice payment thing. But also you could just obfuscate using centralized means, right? And that hasn't popped up yet. We've not truly challenged payments that way. So I don't think that's the main blocker. Okay, another very, very common one. So stablecoins. Very, very hot topic right now. Stablecoins have found PMF, product market fit, mostly as collateral for DeFi stuff, right? They haven't necessarily, or at least early on, they haven't found PMF for payments. We haven't seen that much action in terms of stablecoin payments. It's changing now. I think there's this emerging, very nascent stable coin payments market, which is extremely exciting. But that's also not the main blocker for the crypto rail thesis, because, I mean, if I'm just using it for one hop, so I'm selling my whatever, Polo Slotties here, and then sending them over to Brazil, then it's just one hop over Bitcoin. The next block, I'm already selling it. So the fluctuation of the value doesn't matter too much. And also, it's just false that you can't make payments with a highly volatile currency, right? Like hundreds of countries have, or dozens of countries have highly volatile currencies, and yet somehow people get paid and have salaries and so on. So another thesis, accounts, right? So here the idea is that we need something like account abstraction for mass adoption, better onboarding, stuff like account recovery, more granular permissions. If you think about it, it's kind of crazy that I need exactly the same level of permissions to send $1 and to send $1 million. But again, there should be some subset of payments where all of this doesn't matter because we do have these professionalised custodians we can have like for larger B2b payments we could have all of that so What's needed to unlock? these Payments for everyone to have this peer-to-peer cash that is fully on chain. So I'd like to argue that it's As simple as interoperability with everything else. So I Mentioned early on this guy who was going around garages trying to convince them, hey, adopt our coin for parking fees, and unfortunately they weren't very successful. Well, because it wasn't interoperable with standard ways of paying for parking. So here's the thesis. Interoperability is a necessary condition for interchangeability, which makes money, right? Like, money has to be spendable, which in turn is a necessary condition for any new payment network. So essentially, the idea of bootstrapping a whole payment network from scratch is kind of like that won't work right so what does this mean in practice so in practice this means that we need to slightly defragment parts of our current ecosystem so this is an example from I think a year ago blog post by Vitalik he posed the problem, hey, I have coins on Scrawl, but I want to pay on Tyco. What do I do? Super annoying. If I want USDC, 10 USDC on Optimism, you want 10 USDT on Arbitrum. Super annoying. Another one is, maybe I have some stable coins, but you want fiat. That's a problem we recently asked how we could solve that. And this is what I mean by interoperability. So making it such that it's not one chain, one token, but any chain, any token, and even fiat crypto. So we have a November challenge, which is the no-sex challenge to avoid using centralized exchanges for a whole month. If you want to hit me up, I can share the details later. But back to this idea, how can we achieve this interoperability? Well, it's really, really hard because not all blockchains talk to each other very well. And also fiat and crypto doesn't talk to each other very well. So there needs to be some layers of abstraction that let all of this get routed correctly. And I think one approach is to lock up the funds and then let them be routed where they need to go. And this is something we've been researching for the past one and a half years. But also, I'd like to very briefly mention that it might be the case that payments are currently being eaten by Visa and MasterCard. Crypto payments are being eaten by that because there's this huge emergence of cards, of crypto cards, which I'm using too, by the way. I think they're extremely convenient and a great tool. But we also need to ask ourselves, well, maybe we can skip that step, right? Maybe we can somehow be interoperable in such a way that the merchant receives this raw, simple payment without all of these extra things like the rewards, points, chargebacks, because not for all payment types they're needed, right? So maybe we need to unbundle the payment a little bit. As one of the final notes, I'd like to, this is a quote I found when I was researching for this presentation and it's from 2014. And this was from someone from the Bitcoin Foundation and essentially she said that you can send money over the internet, which is super useful for especially the unbanked, right? So maybe the, it's really interesting for me to see that this was the narrative 10 years ago, and still it's a really, really important part of what we're doing. So, to summarize, we have briefly discussed scalability, where we discovered that for some subset of payments, it shouldn't matter. But if it doesn't matter for these payments, you need these banks to anyway agree, then you might as well go directly through the banks and not use the crypto rails. We've discovered the benefits of account abstraction and easy onboarding for like a mass payment. We briefly discussed stablecoins and what role they could play in the payment space. Then we briefly discussed privacy and the needs there, and, like, is it going to happen? And then, finally, we discussed what interoperability means on a technical level, but I'd also like to briefly touch on the regulatory level, where, essentially, by having regulatory clarity, we can convince more and more of these stratify institutions to be, well, interoperable with our payment systems. So, yeah, long story short, I strongly believe that the next generation of banks will simply skip the neobank stage. So if you think about the Western world, we had traditional banks, then we had Revolut, Monzo, and so on. I think in a lot of emergent economies, we'll simply skip that stage, and the next generation of banks will be partially on-chain banks that are interoperable with TradFi. Yeah. If you want to talk payments, if you want to exchange memes, please DM me. These are my details. Yeah. Open to questions. Alright. Okay. And now we come to the Q&A session. You guys see the QR code on the screen? Any questions for the speaker? Please scan. Okay. Here we go, man. The first one coming. All right. What are your thoughts on agents using stable coins for online purchases? And agents, agent to agents, that's the dead thing, I guess, human payments. Let's go. Yes. Let's do it. I mean, I think, you know, the idea of Intents is much, much broader than just Intents for a swap or a cross-chain swap. Intents can be, you know, just orders for something, and I can just express something like, hey, I want a pizza for so and so many Bitcoin, and someone should be able to go around the world, whether that's a human or an autonomous, well, a bot or AI agent, and solve that for me, right? I think that's clearly something that will happen where all these searches will be done by bots. All right, we have a second question. Second question. Is privacy a blocker for widespread adoption? Yes, but also we don't have widespread adoption yet. So if you think about your payments that you've made, probably this week you've made several dozen payments for coffees, Ubers, maybe to your landlord, maybe you've received a salary that were not on chain. And privacy, yeah, simply, it's too small of a percentage of payments to matter in a big way. So I think it will be a huge problem and will be a blocker, but just not yet. And we have a path forward, right? Like we know how to at least have soft privacy without getting jailed. More questions coming. All right, there's a third one right there. How important is financial literacy? I think hugely important in emergent economies, right? So if you think about emergent economies, the financial products that they have access to, that normal people have access to, are extremely primitive. A lot of people are still saving their salaries in dollars rather than, I don't know, something like the S&P 500 or Ethereum. And they simply don't have access to more sophisticated financial products. All of this will need a lot of education. But for now, I think also we can make more sophisticated financial products accessible to emerging economies through crypto. And we have the fourth question. Can monopolies do anything? Well, yeah, that's a very, very good question. I think the main challenge right now is that Visa and Mastercard have a very, very lucrative reward system, which the merchants pay for, right? So if you think about a credit card payment versus a debit card payment, if you're using a credit card and you're getting some cash back or some other rewards, you're essentially getting subsidized by all the people who paid in cash or with a debit card. I think that's a cycle that's very, very hard to break. And that's why I think the first widespread on-chain payment system will emerge in emerging economies where penetration of Visa and MasterCard isn't that high, and we will have to build our own similar reward system, maybe some crypto-native distribution methods that high and we will have to build our own similar reward system, maybe some crypto native distribution methods like future airdrops and stuff like that might be a very good way to bootstrap a payments network. We have one minute left for the Q&A so maybe we can get this two or three questions. What specific domains or use cases for payments do you think are most promising in the near term? I think we have this incredible explosion of remote work and global work and global teams in crypto. Almost, well, the majority of teams is somehow globally distributed. Payments are frankly a pain in the butt to manage. I think we will see a huge emergence of on-chain payments that then use some kind of localized off-ramps. Yeah. Let's do the last question. Yeah. At what level is adoption? Oh, super low. I mean, we don't know, right? Well, we don't know, because it's very hard to estimate, but I mean, it's definitely sub 1%, and if you account for all payments, and probably sub 0.1%. All right, all right. Thank you, you guys. A big applause to the Urban, please.",
"eventId": "devcon-7",
- "slot_start": 1731573000000,
- "slot_end": 1731574800000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1lEsNi0su_iRPEMbDkw-4CNthY3CMQvM_6ClpF3sBGNM"
+ "slot_start": 1731402000000,
+ "slot_end": 1731403800000,
+ "slot_roomId": "stage-6",
+ "resources_presentation": "https://docs.google.com/presentation/d/1JImpxFx5TF-6ESwxVVo3QOw9b3RrwbHwCF5idb0IZDY",
+ "resources_slides": null,
+ "speakers": [
+ "konrad-urban"
+ ]
},
"vector": [
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -850535,6 +848732,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -851093,7 +849291,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -851123,7 +849320,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -851139,7 +849335,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -851177,6 +849372,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -851266,6 +849462,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -851473,7 +849670,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -851548,6 +849744,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -851576,6 +849773,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -851688,11 +849886,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -851706,42 +849904,37 @@
},
{
"session": {
- "id": "web3-user-research-101",
- "sourceId": "7YZGVW",
- "title": "Web3 User Research 101",
- "description": "Everything you’ve wanted to know about talking to users in web3 and were too afraid to ask! This workshop will give participants a crash course in user research and UX first principles, then guide them through the process of conducting a research project from start to finish - with a focus on web3 users specifically.",
- "track": "Usability",
- "type": "Workshop",
+ "id": "western-liberalism-to-world-liberalism",
+ "sourceId": "H8N9CP",
+ "title": "Western liberalism to world liberalism",
+ "description": "Western liberalism to world liberalism",
+ "track": "Real World Ethereum",
+ "type": "Panel",
"expertise": "Beginner",
- "audience": "Design",
- "featured": true,
+ "audience": "Community",
+ "featured": false,
"doNotRecord": false,
"keywords": [
- "101"
+ "liberalism"
],
"tags": [
- "Best Practices",
- "User Experience",
- "UI/UX",
- "User Research",
- "Design Thinking",
- "101",
- "Best Practices",
- "Design Thinking",
- "UI/UX",
- "User Experience",
- "User Research"
+ "Ethereum for Good",
+ "Free Speech",
+ "Network State"
],
"language": "en",
"speakers": [
- "mindy-harrell",
- "kristina-mayman"
+ "diego-fernandez",
+ "bruno-macaes",
+ "vitalik-buterin",
+ "afra-zhao-wang",
+ "ahmed-gatnash"
],
"eventId": "devcon-7",
- "slot_start": 1731398400000,
- "slot_end": 1731405600000,
- "slot_roomId": "classroom-c",
- "resources_presentation": "https://docs.google.com/presentation/d/1WDegVtKo7rojZIBJT9EVkbEcih7LrcH0QIwcJFOGr6Y"
+ "slot_start": 1731654000000,
+ "slot_end": 1731657600000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1mFj4uTFAQzEJkPvNyUIUkiMCWsX4MObr3w2Rk-bN8Qw"
},
"vector": [
0,
@@ -851750,8 +849943,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -851935,6 +850126,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -852179,6 +850371,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -852262,6 +850455,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -852282,6 +850476,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -852323,6 +850518,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -852467,9 +850663,6 @@
0,
0,
0,
- 6,
- 6,
- 0,
0,
0,
0,
@@ -852512,7 +850705,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -852521,13 +850713,13 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -852541,6 +850733,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -852555,7 +850748,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -852583,7 +850775,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -852621,6 +850812,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -852640,7 +850832,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -853038,7 +851229,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -853066,60 +851256,52 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
- 2,
0,
0
]
},
{
"session": {
- "id": "wen-p2p-electronic-cash-system",
- "sourceId": "ZFX3ZF",
- "title": "Wen p2p Electronic Cash System?",
- "description": "16 years have passed since Bitcoin whitepaper came out. Bitcoin was created as cypherpunk cash replacement. Cash means easy payments. But bitcoin found its PMF as 'digital gold', not as 'digital cash'. What happened to cash? What needs to happen for mass adoption of crypto payments?\r\nWe will go through the history of failed attempts. We'll end up with a hopeful analysis of why it's different in 2024 (spoiler alert: stablecoin adoption, cheap L2s, AA).",
+ "id": "what-defi-founders-can-learn-from-web2",
+ "sourceId": "QB8CGR",
+ "title": "What DeFi Founders Can Learn From Web2",
+ "description": "Most DeFi founders come from crypto native backgrounds, but there is much to learn from the operational mechanics and metrics of web2 companies. \r\n\r\nThis talk will be a brief tutorial about web2 business mechanics, specifically SaaS. Concepts like unit economics, CAC, LTV, ARPU and the science of building and growing scalable companies.",
"track": "Real World Ethereum",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Product",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Business",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Conviction",
- "Payment",
- "Account Abstraction",
- "stablecoin",
- "Account Abstraction",
- "Conviction",
- "Payment"
- ],
+ "tags": [],
"keywords": [
- "payments",
- "cash",
- "stablecoins"
+ "Metrics",
+ "Unit economics",
+ "Growth"
],
- "duration": 1549,
+ "duration": 551,
"language": "en",
- "sources_swarmHash": "63b3f30cc56be0d58d80b8295e68bf9bdc088a286e0e5c0e86738ee20d1e2e1c",
- "sources_youtubeId": "7JFFfcT1yzI",
+ "sources_swarmHash": "2a6da17012439090d0f3e3a01b43f095606ddc22b273ee597298003c1d4338d5",
+ "sources_youtubeId": "BYAUg-nibMs",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673321cc3a168eb53554b6fe.vtt",
- "transcript_text": " Hello. Hello. Cool. Who knows in which year the peer-to-peer electronic cash system paper came out? Anyone else? I'm sure you know. Just three people? Four people? Okay, which year was it? 2008, right? So we're still waiting for that peer-to-peer electronic cash. I think it's fair to say that we've not taken over the peer-to-peer payments world. Bitcoin has definitely found PMF product market fit with store of value. And I don't want to argue that there are no payments on Bitcoin. But clearly, the last payments you've made to come here, maybe with your Grab or Bolt or Uber were probably not Bitcoin or on-chain payments at all. Just to show how ancient this paper is, this is 2008, right? So in 2008, GTA 4 came out. That's how long ago this was. The iPhone just came out a year earlier. People dressed like this. I think it's cool, but also very, very ancient. Bitcoin was largely, well, came out right in time as a perfect reaction to the financial crisis of 2007-2008. This is how long ago it was. a perfect reaction to the financial crisis of 2007-8. This is how long ago it was. I think we all here know what peer-to-peer means, but let's briefly talk about the cash part, because I think it's very easy to think of cash as payments. But payments are not exactly cash. I would say that cash payments are a subset of all payments. And usually when we talk about payments, we talk about something that's much, much more complicated. So last time you ordered your Grab to get here, you made probably a credit card payment. With that there was a very big bundle of services that enabled things like chargebacks, maybe you were using a credit card and definitely there are some points and rewards so I'm still waiting for the visa and MasterCard airdrop. But I would just want to talk about the simplest of payments like this very raw payment which just goes payer to payee without all of these bundled services. So this is what we usually mean by cash payment, right? Like if I give 100 baht to a taxi driver, there's no way to charge back unless I hunt him down somehow. There are also no points and there's definitely not a credit system. So for today, I'd briefly like to talk about why we haven't taken over the world yet and what's needed to take over the world with on-chain payments. So I'll give a mini intro about myself and then we'll go through a mini history just to honor our ancestors. And then I'll talk through five narratives that were popular, or that are popular, to answer, like, this is the blocker. Like, we can't have payments because of, I don't know, scalability, let's say, right? So these will be the five Topics that we'll analyze So about me. I'm the peanut brain at peanut protocol. You can look me up Here and also DM me here So, let's go and honor our ancestors I think I think it's really important to realize the first wave of blockchains and categorize these very briefly. So we had Bitcoin, which I already mentioned, and then we had a bunch of payments projects that were strictly about this cash element, strictly about making payments happen. So I think Litecoin fits that category very well, and Dash definitely does. Stellar, I would say, too. Then we have private payments, Monero and Zcash. The only ones with smart contracts are Nex and Ethereum, by the way. So despite all of these huge ecosystems, well, some of them huge ecosystems, we haven't yet moved cash or payments on-chain. Despite all of these huge ecosystems, well, some of them huge ecosystems, we haven't yet moved cash or payments on-chain. So when I was prepping for this talk, I had the honor to talk to some of these ancestors and people who are working on these very ancient projects. And I asked them, like, how are you going about trying to bootstrap your payment network? And one of the guys I talked to, he was running a campaign in 2017 trying to convince parking garages and, like, very local shops in one local city in the US to adopt their coin as one of the payment methods. As you might guess, it's quite a hopeless endeavor endeavor because you not only have to convince the garages, but also you have to convince all the drivers to adopt your thing in an ecosystem where there is the dollar already and people are used to coins and dollar notes. So what's the advantage of bootstrapping that one token, one chain thing? I think quite similarly, we have... Who's been at ECC this year? Nice. Cool. You might have seen the payments cafe by base. They were selling cappuccinos where you could just take your Coinbase wallet and just make a payment for a cappuccino. And there I wondered, well, isn't it the same case? What's my reason to switch over from that? Like opening up my wallet and so on when I'm so used to just tapping my card, right? Especially that was just USDC on base with which you could pay. So here are the candidates. One common narrative will be scalability. So we need fast and cheap for transactions I'll kind of argue against that then another one is privacy I think highly important in a world where we have full adoption and most payments happen On chain, but I will also argue that we can have a world where settlement happens on chain butts And stuff is still reasonably private. Then another argument that is very common is, well, payments are not on chain yet, or haven't captured a whole payments market in TratFi because stablecoins are relatively new. I'll also argue against that. And then finally, for the 4337 mafia, one common argument is, hey, we need better account management. We have to have account abstraction, all these nice UX improvements. I will also say, well, that's not the main blocker here. And then finally, we'll go into the interrupt thesis. So let's start. I think this is a very common thing, especially in the early days of blockchains. This was a very, very common thing to hear when people were pitching L1s, but also still L2s, right? So the pitch goes something like this. In order to compete with TradFi payments, we have to be similarly cheap and fast. we're pitching L1s, but also still L2s, right? So the pitch goes something like this. In order to compete with TradFi payments, we have to be similarly cheap and fast. So Visa has 24,000 TPS, and my blockchain is so much faster. It has 69,000 TPS, right? I think, again, this kind of, it's a bad comparison because you're comparing these very raw payments of just transferring value from A to B with Visa, which is this very, very complex, very bundled payment solution. And then also, perhaps more importantly for the argument here, is there should be a subset of payments where this doesn't matter right so if i do a one million dollar transaction and there are hundreds of thousands of these happening every day or millions maybe even well definitely millions then it shouldn't matter whether i'm you know using bitcoin um which is slow and relatively expensive. But by the way, what do you think, what are current Bitcoin fees today? If I want to send $1 million to another country, what's the fee on Bitcoin in dollars? Any guesses? Yeah, $1. Yeah, that's not much. You can't do that in Tratva. You can't send $1 million to another country with one buck. You can't do that. Not in that order of magnitude, right? So clearly there should be some subset of payments where it would be more efficient to already use Bitcoin, something as simple as Bitcoin, as the kind of international settlement thing. This is especially true for rare international pairs where normally you would be doing many hops between banks, so the way a TradFi international payment works is you're sending it kind of they're exchanging these IOUs and they have these very custom agreements between each other to trust each other with these IOUs. So when you're sending, let's say, money from Armenia to Chile, it might very well be the case that this payment is going to do five or six hops across the world. So first to a more local bank, and then to another one, maybe then to some US bank, and then finally to some Latin bank, and then finally to Chile. In the meantime, you don't know where the payment is and the fees you don't know how much each intermediary is going to collect. So already this should be more, even with Bitcoin, something as primitive as Bitcoin, like V1 of blockchains, it should be more efficient. But guess what? Here's my startup idea. Why don't we do a TransferWise but with Bitcoin rails? So the way TransferWise works is you have these bank accounts in different countries, and then they kind of just internally settle the payment. So they front it for you. They receive it in one country, then they front it to you in the other country. Well, here's the problem. For that to happen, you would need two banks to agree not to ban you for your Bitcoin payments. So if you can convince two banks not to ban you because you're not fitting their AML requirements or they don't know what you're doing or they're just scared of Bitcoin or they think it's like some shady thing, then you might as well just have a normal, very classical IOU-type contract with these guys to just do a normal settlement. So if you've identified this pair where there's a lot of sudden trade happening, and it's not been captured yet, let's say, I don't know, Chileans suddenly get obsessed about Ethiopian coffee, if suddenly there's a lot of trade happening, immediately there will be someone who will try to capture those flows to avoid all these inefficiencies with these hops, right? And you can do so with IOUs for these large transactions. So this very convincing narrative, like when you hear it for the first time, oh yeah, sure, let's use crypto rails just for the international part, is actually maybe not as strong for these larger B2B transactions, especially when it comes to global supply chains. Cool. Another narrative, privacy. Well, we can't penetrate the whole market unless we have privacy. Obviously, if I go somewhere and I buy my coffee, I don't want to broadcast that to literally the entire world that I just bought a pumpkin spice latte. That's extremely embarrassing, and I don't want other people to know. I think, well, again, that does not much for the just Rails thesis, because you could have some kind of company that wraps Monero or Zcash or some other solution and makes it into a nice payment thing. But also you could just obfuscate using centralized means, right? And that hasn't popped up yet. We've not truly challenged payments that way. So I don't think that's the main blocker. Okay, another very, very common one. So stablecoins. Very, very hot topic right now. Stablecoins have found PMF, product market fit, mostly as collateral for DeFi stuff, right? They haven't necessarily, or at least early on, they haven't found PMF for payments. We haven't seen that much action in terms of stablecoin payments. It's changing now. I think there's this emerging, very nascent stable coin payments market, which is extremely exciting. But that's also not the main blocker for the crypto rail thesis, because, I mean, if I'm just using it for one hop, so I'm selling my whatever, Polo Slotties here, and then sending them over to Brazil, then it's just one hop over Bitcoin. The next block, I'm already selling it. So the fluctuation of the value doesn't matter too much. And also, it's just false that you can't make payments with a highly volatile currency, right? Like hundreds of countries have, or dozens of countries have highly volatile currencies, and yet somehow people get paid and have salaries and so on. So another thesis, accounts, right? So here the idea is that we need something like account abstraction for mass adoption, better onboarding, stuff like account recovery, more granular permissions. If you think about it, it's kind of crazy that I need exactly the same level of permissions to send $1 and to send $1 million. But again, there should be some subset of payments where all of this doesn't matter because we do have these professionalised custodians we can have like for larger B2b payments we could have all of that so What's needed to unlock? these Payments for everyone to have this peer-to-peer cash that is fully on chain. So I'd like to argue that it's As simple as interoperability with everything else. So I Mentioned early on this guy who was going around garages trying to convince them, hey, adopt our coin for parking fees, and unfortunately they weren't very successful. Well, because it wasn't interoperable with standard ways of paying for parking. So here's the thesis. Interoperability is a necessary condition for interchangeability, which makes money, right? Like, money has to be spendable, which in turn is a necessary condition for any new payment network. So essentially, the idea of bootstrapping a whole payment network from scratch is kind of like that won't work right so what does this mean in practice so in practice this means that we need to slightly defragment parts of our current ecosystem so this is an example from I think a year ago blog post by Vitalik he posed the problem, hey, I have coins on Scrawl, but I want to pay on Tyco. What do I do? Super annoying. If I want USDC, 10 USDC on Optimism, you want 10 USDT on Arbitrum. Super annoying. Another one is, maybe I have some stable coins, but you want fiat. That's a problem we recently asked how we could solve that. And this is what I mean by interoperability. So making it such that it's not one chain, one token, but any chain, any token, and even fiat crypto. So we have a November challenge, which is the no-sex challenge to avoid using centralized exchanges for a whole month. If you want to hit me up, I can share the details later. But back to this idea, how can we achieve this interoperability? Well, it's really, really hard because not all blockchains talk to each other very well. And also fiat and crypto doesn't talk to each other very well. So there needs to be some layers of abstraction that let all of this get routed correctly. And I think one approach is to lock up the funds and then let them be routed where they need to go. And this is something we've been researching for the past one and a half years. But also, I'd like to very briefly mention that it might be the case that payments are currently being eaten by Visa and MasterCard. Crypto payments are being eaten by that because there's this huge emergence of cards, of crypto cards, which I'm using too, by the way. I think they're extremely convenient and a great tool. But we also need to ask ourselves, well, maybe we can skip that step, right? Maybe we can somehow be interoperable in such a way that the merchant receives this raw, simple payment without all of these extra things like the rewards, points, chargebacks, because not for all payment types they're needed, right? So maybe we need to unbundle the payment a little bit. As one of the final notes, I'd like to, this is a quote I found when I was researching for this presentation and it's from 2014. And this was from someone from the Bitcoin Foundation and essentially she said that you can send money over the internet, which is super useful for especially the unbanked, right? So maybe the, it's really interesting for me to see that this was the narrative 10 years ago, and still it's a really, really important part of what we're doing. So, to summarize, we have briefly discussed scalability, where we discovered that for some subset of payments, it shouldn't matter. But if it doesn't matter for these payments, you need these banks to anyway agree, then you might as well go directly through the banks and not use the crypto rails. We've discovered the benefits of account abstraction and easy onboarding for like a mass payment. We briefly discussed stablecoins and what role they could play in the payment space. Then we briefly discussed privacy and the needs there, and, like, is it going to happen? And then, finally, we discussed what interoperability means on a technical level, but I'd also like to briefly touch on the regulatory level, where, essentially, by having regulatory clarity, we can convince more and more of these stratify institutions to be, well, interoperable with our payment systems. So, yeah, long story short, I strongly believe that the next generation of banks will simply skip the neobank stage. So if you think about the Western world, we had traditional banks, then we had Revolut, Monzo, and so on. I think in a lot of emergent economies, we'll simply skip that stage, and the next generation of banks will be partially on-chain banks that are interoperable with TradFi. Yeah. If you want to talk payments, if you want to exchange memes, please DM me. These are my details. Yeah. Open to questions. Alright. Okay. And now we come to the Q&A session. You guys see the QR code on the screen? Any questions for the speaker? Please scan. Okay. Here we go, man. The first one coming. All right. What are your thoughts on agents using stable coins for online purchases? And agents, agent to agents, that's the dead thing, I guess, human payments. Let's go. Yes. Let's do it. I mean, I think, you know, the idea of Intents is much, much broader than just Intents for a swap or a cross-chain swap. Intents can be, you know, just orders for something, and I can just express something like, hey, I want a pizza for so and so many Bitcoin, and someone should be able to go around the world, whether that's a human or an autonomous, well, a bot or AI agent, and solve that for me, right? I think that's clearly something that will happen where all these searches will be done by bots. All right, we have a second question. Second question. Is privacy a blocker for widespread adoption? Yes, but also we don't have widespread adoption yet. So if you think about your payments that you've made, probably this week you've made several dozen payments for coffees, Ubers, maybe to your landlord, maybe you've received a salary that were not on chain. And privacy, yeah, simply, it's too small of a percentage of payments to matter in a big way. So I think it will be a huge problem and will be a blocker, but just not yet. And we have a path forward, right? Like we know how to at least have soft privacy without getting jailed. More questions coming. All right, there's a third one right there. How important is financial literacy? I think hugely important in emergent economies, right? So if you think about emergent economies, the financial products that they have access to, that normal people have access to, are extremely primitive. A lot of people are still saving their salaries in dollars rather than, I don't know, something like the S&P 500 or Ethereum. And they simply don't have access to more sophisticated financial products. All of this will need a lot of education. But for now, I think also we can make more sophisticated financial products accessible to emerging economies through crypto. And we have the fourth question. Can monopolies do anything? Well, yeah, that's a very, very good question. I think the main challenge right now is that Visa and Mastercard have a very, very lucrative reward system, which the merchants pay for, right? So if you think about a credit card payment versus a debit card payment, if you're using a credit card and you're getting some cash back or some other rewards, you're essentially getting subsidized by all the people who paid in cash or with a debit card. I think that's a cycle that's very, very hard to break. And that's why I think the first widespread on-chain payment system will emerge in emerging economies where penetration of Visa and MasterCard isn't that high, and we will have to build our own similar reward system, maybe some crypto-native distribution methods that high and we will have to build our own similar reward system, maybe some crypto native distribution methods like future airdrops and stuff like that might be a very good way to bootstrap a payments network. We have one minute left for the Q&A so maybe we can get this two or three questions. What specific domains or use cases for payments do you think are most promising in the near term? I think we have this incredible explosion of remote work and global work and global teams in crypto. Almost, well, the majority of teams is somehow globally distributed. Payments are frankly a pain in the butt to manage. I think we will see a huge emergence of on-chain payments that then use some kind of localized off-ramps. Yeah. Let's do the last question. Yeah. At what level is adoption? Oh, super low. I mean, we don't know, right? Well, we don't know, because it's very hard to estimate, but I mean, it's definitely sub 1%, and if you account for all payments, and probably sub 0.1%. All right, all right. Thank you, you guys. A big applause to the Urban, please.",
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673456ff9dbb7a90e114e68a.vtt",
+ "transcript_text": " Hello. Hello. All right, so this is going to be a quick one. So I'll try to go fast, but hopefully keep it comprehensible. So yeah, my name is Mike Seligadze. I'm founder and CEO of EtherFi. And my lens on the crypto space is that I come from a Web2 background. And so one of the things that I want to talk about is what are some of the lessons that Web3 founders can learn from the Web2 universe? So just to give you a little bit about my background, I got into crypto super early, bought some Bitcoin back in 2011. That's like the actual confirmation email. It was about a dollar per Bitcoin at that time. There weren't even exchanges. I had to just PayPal some money to a random guy on an internet forum, which was fun. Then around the same time, I started a company called Top Hat, which was a web two company in B2B SaaS. So specifically, we were doing education software for universities, which is a very challenging market to be in. I spent about 10 years growing that company. It ended up being pretty successful. We got it up to around 450 employees, about 65 million revenue, and then sold it in 2021. It was a great, great outcome. And so then I decided to do pretty much the exact opposite, as far as you can get from education software, which was my first passion, crypto, and started Etherfy around 2022. And that's gone remarkably well. We've been humbled at all our success. We're the number four DeFi protocol by TVL, at least about $8 billion in TVL given current ETH price. And, yeah, around $30 million in revenue and growing super fast. You know, couldn't be more excited about it. One of the reasons I would say that EtherFi has been successful is because we've taken sort of the discipline and mechanics of operation of the business and brought it to the DeFi world. And so what I want to do is just talk about, you know, what are some of those lessons. You know, the curse of crypto is that there's way too much money in the space. You know, there's just a ton of gambling money coming from the great, you know, cas curse of crypto is that there's way too much money in the space. You know, there's just a ton of gambling money coming from the great, you know, casinos in the sky. And that actually, the effect that ends up having is crowding out real product development because it basically eliminates the need in many cases for getting product market fit. If you're doing, you know, a Web2, more traditional SaaS type of business, the cycle of that business looks roughly like this. You acquire a customer. You get the customer to give you dollars. You then keep that customer by providing a good service. Then you reinvest that back into R&D, and then the customer is happy, and there's a nice positive feedback loop. In Web 3.0, it looks a little bit different. Usually, you find a project that's really cool, maybe a nice DEX. You launch a token, you vest your tokens, you cash out, and then you're done. It's a great business model, super easy to make really shocking amounts of money doing it that way. But when the main business model is basically printing casino chips and then taking a rake, you know, this is why we can't have nice things. So what I'd like to do is talk about, like, what are some of the principles that.",
"eventId": "devcon-7",
- "slot_start": 1731402000000,
- "slot_end": 1731403800000,
- "slot_roomId": "stage-6",
- "resources_presentation": "https://docs.google.com/presentation/d/1JImpxFx5TF-6ESwxVVo3QOw9b3RrwbHwCF5idb0IZDY",
+ "slot_start": 1731480600000,
+ "slot_end": 1731481200000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Gix77PnI2mYDQXanQIb49GstVRHx_-5qwgYKGNsIxzs",
"resources_slides": null,
"speakers": [
- "konrad-urban"
+ "mike-silagadze"
]
},
"vector": [
@@ -853284,7 +851466,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -853846,6 +852027,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -853926,7 +852108,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -854016,7 +852197,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -854299,7 +852479,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -854330,7 +852509,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -854436,10 +852614,10 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -854453,51 +852631,47 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "western-liberalism-to-world-liberalism",
- "sourceId": "H8N9CP",
- "title": "Western liberalism to world liberalism",
- "description": "Western liberalism to world liberalism",
- "track": "Real World Ethereum",
- "type": "Panel",
- "expertise": "Beginner",
- "audience": "Community",
+ "id": "what-dont-we-know-understanding-security-vulnerabilities-in-snarks",
+ "sourceId": "NL3A7T",
+ "title": "What don't we know? Understanding Security Vulnerabilities in SNARKs",
+ "description": "Zero-knowledge proofs (ZKPs) have evolved from being a theoretical concept providing privacy and verifiability to having practical, real-world implementations, with SNARKs (Succinct Non-Interactive Argument of Knowledge) emerging as one of the most significant innovations. Prior work has mainly focused on designing more efficient SNARK systems and providing security proofs for them. Many think of SNARKs as \"just math,\" implying that what is proven to be correct and secure is correct in practice.",
+ "track": "Security",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "liberalism"
+ "ZKPs",
+ "Security"
],
"tags": [
- "Ethereum for Good",
- "Free Speech",
- "Network State"
+ "Security"
],
"language": "en",
"speakers": [
- "diego-fernandez",
- "bruno-macaes",
- "vitalik-buterin",
- "afra-zhao-wang",
- "ahmed-gatnash"
+ "stefanos-chaliasos"
],
"eventId": "devcon-7",
- "slot_start": 1731654000000,
- "slot_end": 1731657600000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1mFj4uTFAQzEJkPvNyUIUkiMCWsX4MObr3w2Rk-bN8Qw"
+ "slot_start": 1731643200000,
+ "slot_end": 1731645000000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1b-4F9L2PRDflpHb2iAzeGwsuH6cvqfh3FMJsnOPZOtc"
},
"vector": [
+ 6,
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -854681,7 +852855,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -854926,7 +853099,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -855014,7 +853186,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -855035,7 +853206,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -855077,7 +853247,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -855219,6 +853388,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -855243,6 +853414,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -855270,7 +853442,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -855290,7 +853461,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -855369,7 +853539,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -855810,10 +853979,12 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -855826,48 +853997,42 @@
},
{
"session": {
- "id": "what-defi-founders-can-learn-from-web2",
- "sourceId": "QB8CGR",
- "title": "What DeFi Founders Can Learn From Web2",
- "description": "Most DeFi founders come from crypto native backgrounds, but there is much to learn from the operational mechanics and metrics of web2 companies. \r\n\r\nThis talk will be a brief tutorial about web2 business mechanics, specifically SaaS. Concepts like unit economics, CAC, LTV, ARPU and the science of building and growing scalable companies.",
- "track": "Real World Ethereum",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Business",
+ "id": "what-is-the-status-of-epbs-and-its-future-iterations",
+ "sourceId": "3MUYVQ",
+ "title": "What is the status of ePBS and its future iterations",
+ "description": "We will go over the implementation and research status of ePBS (EIP-7732) and the future iterations and mechanisms it enables.We will describe in detail the main benefits to the protocol that are not directly related to any PBS system. We will showcase the tradeoffs that are present on each design decision and how the separation of validation between the consensus and execution layer in fact frees research with less technical debt and more independent mechanisms for future upgrades.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [],
"keywords": [
- "Metrics",
- "Unit economics",
- "Growth"
+ "PBS",
+ "consensus",
+ "fork-choice"
+ ],
+ "tags": [
+ "PBS",
+ "fork",
+ "choice",
+ "PBS"
],
- "duration": 551,
"language": "en",
- "sources_swarmHash": "2a6da17012439090d0f3e3a01b43f095606ddc22b273ee597298003c1d4338d5",
- "sources_youtubeId": "BYAUg-nibMs",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673456ff9dbb7a90e114e68a.vtt",
- "transcript_text": " Hello. Hello. All right, so this is going to be a quick one. So I'll try to go fast, but hopefully keep it comprehensible. So yeah, my name is Mike Seligadze. I'm founder and CEO of EtherFi. And my lens on the crypto space is that I come from a Web2 background. And so one of the things that I want to talk about is what are some of the lessons that Web3 founders can learn from the Web2 universe? So just to give you a little bit about my background, I got into crypto super early, bought some Bitcoin back in 2011. That's like the actual confirmation email. It was about a dollar per Bitcoin at that time. There weren't even exchanges. I had to just PayPal some money to a random guy on an internet forum, which was fun. Then around the same time, I started a company called Top Hat, which was a web two company in B2B SaaS. So specifically, we were doing education software for universities, which is a very challenging market to be in. I spent about 10 years growing that company. It ended up being pretty successful. We got it up to around 450 employees, about 65 million revenue, and then sold it in 2021. It was a great, great outcome. And so then I decided to do pretty much the exact opposite, as far as you can get from education software, which was my first passion, crypto, and started Etherfy around 2022. And that's gone remarkably well. We've been humbled at all our success. We're the number four DeFi protocol by TVL, at least about $8 billion in TVL given current ETH price. And, yeah, around $30 million in revenue and growing super fast. You know, couldn't be more excited about it. One of the reasons I would say that EtherFi has been successful is because we've taken sort of the discipline and mechanics of operation of the business and brought it to the DeFi world. And so what I want to do is just talk about, you know, what are some of those lessons. You know, the curse of crypto is that there's way too much money in the space. You know, there's just a ton of gambling money coming from the great, you know, cas curse of crypto is that there's way too much money in the space. You know, there's just a ton of gambling money coming from the great, you know, casinos in the sky. And that actually, the effect that ends up having is crowding out real product development because it basically eliminates the need in many cases for getting product market fit. If you're doing, you know, a Web2, more traditional SaaS type of business, the cycle of that business looks roughly like this. You acquire a customer. You get the customer to give you dollars. You then keep that customer by providing a good service. Then you reinvest that back into R&D, and then the customer is happy, and there's a nice positive feedback loop. In Web 3.0, it looks a little bit different. Usually, you find a project that's really cool, maybe a nice DEX. You launch a token, you vest your tokens, you cash out, and then you're done. It's a great business model, super easy to make really shocking amounts of money doing it that way. But when the main business model is basically printing casino chips and then taking a rake, you know, this is why we can't have nice things. So what I'd like to do is talk about, like, what are some of the principles that.",
- "eventId": "devcon-7",
- "slot_start": 1731480600000,
- "slot_end": 1731481200000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1Gix77PnI2mYDQXanQIb49GstVRHx_-5qwgYKGNsIxzs",
- "resources_slides": null,
"speakers": [
- "mike-silagadze"
- ]
+ "potuz"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731472200000,
+ "slot_end": 1731474000000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1hihFfnTMBS1Mmp0aS3oHwzA-PX43SVRFqlRfNkbtOwU"
},
"vector": [
0,
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -856587,11 +854752,8 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
0,
+ 6,
0,
0,
0,
@@ -856655,6 +854817,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -857045,6 +855208,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -857157,6 +855321,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -857174,6 +855339,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -857182,8 +855348,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -857197,40 +855361,50 @@
},
{
"session": {
- "id": "what-dont-we-know-understanding-security-vulnerabilities-in-snarks",
- "sourceId": "NL3A7T",
- "title": "What don't we know? Understanding Security Vulnerabilities in SNARKs",
- "description": "Zero-knowledge proofs (ZKPs) have evolved from being a theoretical concept providing privacy and verifiability to having practical, real-world implementations, with SNARKs (Succinct Non-Interactive Argument of Knowledge) emerging as one of the most significant innovations. Prior work has mainly focused on designing more efficient SNARK systems and providing security proofs for them. Many think of SNARKs as \"just math,\" implying that what is proven to be correct and secure is correct in practice.",
- "track": "Security",
+ "id": "whats-going-into-the-pectra-upgrade",
+ "sourceId": "9WTJRX",
+ "title": "What’s Going Into the Pectra Upgrade?",
+ "description": "A talk explaining the core EIPs going into the Pectra upgrade and the core EIPs still TBD for inclusion in Pectra. The talk will also touch on Pectra timing and fork scoping for the next hard fork after Pectra. Finally, the talk will share insights about the governance process of Ethereum in light of Pectra and takeaways about the priorities of Ethereum protocol developers.",
+ "track": "Core Protocol",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "ZKPs",
- "Security"
- ],
"tags": [
- "Security"
+ "fork",
+ "hard"
],
- "language": "en",
- "speakers": [
- "stefanos-chaliasos"
+ "keywords": [
+ "Pectra",
+ "Governance",
+ "Hard forks"
],
+ "duration": 1515,
+ "language": "en",
+ "sources_swarmHash": "9c19d1c251eda5ae03524a901f817d1fb823edb289430285e2f1c606f649b80f",
+ "sources_youtubeId": "ufIDBCgdGwY",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f5e180d989c5b7ab5730.vtt",
+ "transcript_text": " On what is going into the Pectra upgrade, we're going to talk about all the EOPs that are going into the Pectra upgrade. Quick disclaimer before I start, everything I'm about to say is all informational, for informational purposes, should not be construed as financial or investment advice. Before we get into what's going into Pectra, the question that I get asked the most is when Pectra is going on to mainnet. So I'm just going to get that out of the way so we can get into the technical stuff. This is a very tentative timeline analysis, and everyone's taking pictures already. When people ask me, when is Pectra going to happen? I say it's too early to tell because it's true. Pektra is still in very early stages of its development. Specifications are changing. The scope of Pektra even has not really truly been finalized quite yet, as we'll talk about. But through this process, one of the things that you can learn is how upgrades get developed, how upgrades get tested, and eventually make it onto main net. So initially what happens is developers decide on a couple of EIPs to include in an upgrade, and then they implement those EIPs onto private developer-focused test nets called DevNets. And developers have already launched a couple of DevNets already for Pektra, so these EIPs have already undergone a couple of rounds of implementation, and developers have noticed edge cases, have noticed various bugs that they want to fix, and they iterate. They iterate on these EIPs by launching new DevNets. DevNet 4 was launched last month, October. And this doesn't usually happen, but developers, very specially for this entire conference and for everybody in the audience, launched the first public Pektra testnet. This month, it's called Mekong. So you can go and interact with some of the EIPs that are going to be in Pektra early on. It's based on DevNet 4 specifications. But please note that those specifications are changing. There is a list of changes, specifications changes to the EIPs that developers already want to include into Pektra DevNet 5. So there's things like BLS precompile repricing, a new EIP that hasn't been implemented into DevNet 4, but developers are aiming to implement it in for DevNet 5 or a future upgrade. So Pektra specifications are changing. I foresee multiple more dev nets still to go before specifications can really be frozen. And the other part that's really important for the Pektra upgrade in its progress to mainnet is for the scope to be finalized. For all of the EIPs going into Pektra to be decided upon with developers. And there is one EIP. It's not really an EIP yet. But it's the blob capacity increase. That is what developers have not yet formally included into Pectra. But it seems as though they're likely to include a blob capacity increase, some kind of a blob capacity increase into Pectra because of the fact that they have recently included this EIP, which we're going to talk about, which introduces a mechanism to be able to update the blob gas target and the blob gas max dynamically through the consensus layer, rather than having those parameters hard coded in the execution layer and the consensus layer. So the addition of that mechanism into Pectra suggests that developers are doing all the heavy lifting of trying to implement a change to the blob capacity increase or a change to the blob capacity in Pektra. But developers have not formally decided or formally included that increase. Right now it's a target of three and a max of six. They're not sure if it's going to be an increase of four or five or six. So ideally, hopefully, developers will be able to finalize that early next year. And I think as the specifications for the other Pectra EIPs become hardened, more finalized, it puts pressure on developers to kind of activate them on main net. And in order to do that, you have to ensure that the scope of the upgrade is fully complete. So strong, I guess, like thinking or reasoning that the Pectra scope will be finalized by early next year. And then once it is finalized, you start testing whatever new EIPs that you've implemented, the full scope of the Pectra upgrade, you test that and battle test it on a couple more DevNets. I envision, say, you know, until maybe DevNet 6 or 7. And then once the Pectra specifications are frozen, they are ready to go, all the edge cases that developers can find on DevNets have been found, they will then release the Pektra specifications, developers have budgeted about two weeks between public testnet upgrades. In kind of rare occasions, developers kind of shrunk that timeline down to even just one week between testnets. But because of the size of Pectra, I imagine that developers will want to take the full time to see how the Pectra upgrade fares on public testnet environments. So I am budgeting roughly about a month for the Sepolia and the Holesky. Holesky, I don't even know how you say it right, but Holesky. Thank you, sir. Yeah, so that's going to happen. And I'm budgeting about a month for that. And then after, that's when you can finally have the mainnet activation. So given all of the information that I know right now and the progress that developers have made so far on Pectra, my best analysis and guess is that Pectra mainnet will realistically happen next April 2025. Again, this is very tentative because a lot can change between now and April. Development happens on a week-to-week basis. Developers are on these ACD calls talking about this bug that they didn't expect in this EIP. Or this new EIP that they do want to add into Pektra now. So a lot of things can change this timeline. But looking into my crystal ball, there you have it, my timeline. Let's move on to what is the meat, you know, the bread and butter of this talk, which is what is going into the Pectra upgrade. There are 10 EIPs that are going into Pectra. And four of them are focused on the execution layer. Oh, my gosh, the print is so small there. EIP-2537. It is a new precompile. Yay. a new precompile, yay, new precompile into the EVM, BLS12381 curve operation. This is a new cryptographic signature scheme that smart contract developers have been asking for for a very long time. This is an EAP that was created in 2020. And at the time, dApp developers were like, we really want this because it would give dApps, certain dApps that are relying on zero knowledge cryptography, stronger privacy guarantees, potentially increased security and scalability. I believe BLS signatures, that signature scheme or that aggregation is also the signature aggregation that happens on the consensus layer for validator attestations. This EIP is a long time coming. And so I think one of the concerns around this EIP is, are there still apps that are waiting for the BLS precompile? And are they going to use it when that precompile goes live? So kind of an open question. But if you're in this audience and didn't know that the BLS precompile is finally coming, it's coming. And maybe, you know, you have an app that hasn't already moved on from this vision and can still utilize this precompile in some pretty cool ways. So it's going into Pectra. EIP-2935 serve historical block hashes from state. This one introduces a change to the execution layer such that proofs of historical blocks can be generated from the state. This does have some near-term benefits. So it has some benefits for light client syncing, has some benefits for smart contracts that may want to utilize data about the state of a prior block directly through the EVM. You can't actually do that right now. But those near-term benefits is not the reason that this EIP was included into Pektra. Because clearly those benefits are a little bit iffy. Not like super important, I guess. But the main reason why that was included into Pektra is because it's a prerequisite for Verkl. And Verkl is this major overhaul to Ethereum's structure for state data on Ethereum. That developers had thought that transition was going to happen right after Pektra. So they're like, oh, you know, Fusaka, this is when Verkl's going to happen. Oh, well, we need this EAP if we're going to do that Verkl transition. But turns out, as we're going to talk later in this presentation, Verkl's not going to go into Fusaka, or at least that's not what developers are expecting right now. They've punted it out to another upgrade. But it's still there. Developers did implement it and it will have some near-term benefits. But the primary reason for it is as a prerequisite to Verkl, which, you know, could happen down the road. And if it does, you know, this stepping stone has already been checked off the list. EIP-7685, general purpose execution layer requests. This is an EIP that doesn't really introduce new features to Ethereum. It's really an EIP to support other EIPs in Pectra. So in Pectra, there's a couple of other EIPs where the execution layer will be able to pass way more messages, different kinds of messages to the consensus layer that it couldn't before. The execution layer, smart contracts on the execution layer will be able to trigger like validator withdrawals, consolidations, deposits. And rather than implementing these new messages, these new communication channels, all in a separate kind of unique fashion, the implementation of these generalized, these execution layer triggerable requests, the implementation of all these requests, instead of doing it in kind of like a siloed fashion, why not create like a generalized structure, a generalized bus to house these requests? It will be easier to test, easier to implement across clients, easier to kind of standardize, especially if developers want to introduce new types of execution layer triggerable requests. So Geth developer, like client, he was like, I think this would be a good EIP to add. Once developers started implementing those other EIPs, they're like, oh, actually, this is something that would be pretty useful. So that's why EIP 7685 is in there, an EIP to support the other EIPs. EIP 7702, this one's kind of, I guess, an exciting one. A new transaction type is coming into Ethereum, and this transaction type is going to temporarily allow a user-controlled account, an EOA, externally owned account, to have greater flexibility and enable features like some that I think many people in the audience have been waiting for for a while, to enable EOAs to have features like transaction batching, sponsored transactions, conditional transactions, delegated security. Pretty cool stuff. Like you're thinking, oh my gosh, is this like the account abstraction vision coming alive on Ethereum? No, it's not. It's a baby step. So it's kind of like a baby step to seeing how this will improve the user experience. It is cool that some kind of temporary functionality that you'll be able to create some kind of temporary new flexibility into EOAs. But really it's an early step to see what the real roadmap to true native account abstraction could look like on Ethereum. This had quite a bit of debate in terms of how developers should take that first step. A lot of controversy of this one getting in and its design. But it's in there. And I'm pretty sure of all the EIPs that developers want you to interact with and kind of test on the Mekong testnet, this is probably high up on the list. You know, trying out this new transaction type. So if you're on Mekong, you know, throw developers a bone. Try it out. There are six others. These ones are consensus layer EIPs. I'm going to run through these really quickly. Because after me there's going to be some talks that go deeper into each of these EIPs. So this is just, you know, summary overview. EIP 7742 uncoupled blob count between the consensus layer and the execution layer. This one is the most recent EIP to be included into Pectra. Developers, like I said, was considering should we include an increase to the blob capacity? And if we're going to do that, currently the blob capacity is hard-coded into the execution layer and the consensus layer. And the hard-coding of these constants are all kind of different in all the clients. And so updating that hard coding is not as easy as some may think. So creating a mechanism to kind of be able to change the blob capacity and have it dynamically set by the consensus layer will ensure that in the future developers can easily change the blob capacity of Ethereum if they want to. And ensure that that kind of upgrade, it only requires consensus layer changes, doesn't require a change to both the execution layer and the consensus layer. So, yeah. But it's like heavy work up front, right? Because the mechanism doesn't exist right now. Once the mechanism exists, yes, it will be easy to use that mechanism increase, the blob capacity in Pectra, we should really get started on this mechanism sooner rather than later. And so developers were like, actually, yes, other developers on the call, on the ACD calls I'm talking about. They're like, you know what, that's probably a good idea. So that's why it was included. Developers have not decided on what specifically that increase is going to be quite yet. Let's dive deeper into some of these other ones. EIP6110, supply to validate deposits on chain. Vitalik, he was like, woohoo, in the main stage talk, like the merge happened. The merge did happen. And Ethereum is more mature as a proof of stake blockchain. There are certain security assumptions that can be relaxed now. And one of those security assumptions is an additional round of voting that happens every time you deposit a 32 ETH on the Ethereum 2.0 deposit contract. There's an additional round of voting that happens on the consensus layer side to verify those deposits. This EIP removes that additional round of voting on the consensus layer side, ensures all the deposit validation happens on the consensus layer side ensures all the deposit validation happens on the execution layer. This has some benefits for validator UX. It will shrink the time between when you deposit your 32 ETH and when you see the validator actually be activated on the beacon chain. EIP7002, execution layer triggerable withdrawals. This is very good for staking pools. Right now, validators, if you want to fully withdraw a validator, the node operator that controls, that operates that validator needs to withdraw, they need to use their withdrawal key to fully exit the validator. But through the CIP, smart contracts will be able to initiate those full withdrawals. So it's kind of a trust assumption that you can now remove from staking pools. The likes of, say, like Lido, Rocket Pool, other smart contract-based staking pools, you can ‑‑ those smart contracts can now trigger full withdrawals of validators if they wish. So a very nice feature for trustlessness and improving the, yes, I don't know, like resiliency, yes, resiliency of smart contract-based staking pools. EIP-7251, increasing the maximum effective balance. I have written so many reports on the problem of Ethereum's growing validator set size. This really is an issue. I guess, you know, when developers were thinking about the beacon chain, they did not expect the validator set to grow so quickly and for the peer-to-peer network of Ethereum not to be able to handle 1.5 million validators. I think we're at like 1.2 or 1.3. Somebody can check me on that. But there's a lot of validators, a lot of active validators, a lot of messages being passed around on the networking layer, and it's too much. It really is too much. So it's straining nodes, and left unchecked, it would be a major problem for the health of Ethereum. So EIP-7251 is designed to encourage validators to consolidate their ETH and have a maximum effective balance higher than 32 ETH and reduce the number of active validators on Ethereum. That is the goal of EIP-7251. Let's see how quickly it is adopted once Pectra goes live because that, you know, depends on all of the staking pools and stakeholders of the staking community really, you know, getting it together, okay? So EIP-7549, move committee index outside attestation, kind of like a restructuring, refactoring of the way that attestations are aggregated to make blocks, or to reduce the networking load of Ethereum. Again, see, there's clearly networking pains, and save node bandwidth. And kind of a quick note about the CIP, developers when they were including it in Pektra, this is a great change, clearly has wonderful benefits, an easy one to go ahead with. In practice, though, turned out to be a lot harder to implement than expected. So sometimes that's the way the cookie crumbles. Wow. I cannot believe I only have two more minutes. Okay. So in like the outlook, if you know, I blazed through that really fast. Don't worry. In summary, Petra is a mixed bag of updates. It's going to do three things. It's going to fix critical shortcomings of Ethereum as a proof of stake blockchain. Think about max EB, right? Like that's a critical fix that needs to happen because the validator set size can continue to grow unchecked. Improve the user experience, right? We're talking about, like, the new transaction type, making it always more flexible, some improvements for more trustless designs for staking pools, etc. Some minor UX improvements there. And number three, Ethereum's data availability capacity, increasing that. That hasn't been formally included into Pectra, but again, seems likely. Moving on. Okay, here are all the EIPs that were removed from Pectra. This is kind of like a first-time thing for an upgrade to have so many EIPs removed from it. The first one is PeerDAS. Honestly, there was going to be a much bigger increase to data availability capacity in Pectra. Initially, when Pectra was being scoped out, PeerDAS is going to allow developers to increase the blob target of Ethereum, not from like three to four to like four to five, but like by multiples more without impacting greatly the bandwidth consumption and the computational requirements of running an Ethereum node. But it's still in research and development phase. It's still being developed. And these other 11 code changes as a bundle are called EOF. It's this major update to the Ethereum EVM. And both of these EIPs, all these EIPs were initially included in Pectra, but they were being tested on separate devnets. So you had the Pectra EIPs that were moving along, progressing, starting to solidify, starting to become more aspects of it were starting to become more or less finalized. But PeerDAS and EOF, there were developers thought that it would require a lot more time to get them really ready for mainnet activation, and developers did not want to delay the activation of the Pektra EIPs from getting onto mainnet, which is why one of the reasons was they wanted to get Pectra EIPs out sooner. So they said PeerDAS and EOF clearly needs more time to be worked on. We'll pump that to another upgrade and not hold back these other Pectra EIPs from mainnet. Another reason is this is a lot of EIPs in addition to the other ten that I talked about, so lots of risk, right? With the interdependencies of the code, trying to implement it all at once. This is a lot of work and time for the testing team and the client teams to be able to ensure there aren't any bugs. So lots of reasons for two, I would say, actually main reasons for why these EIPs were removed from Pectra. And now they are moved to Fusaka. So again, I have Verkl up there because Verkl was initially slated for Fusaka, but then now it's not going to because developers have given a soft confirmation that EOF and PeerDAS are going to be in Fusaka. But again, obviously, changes happen. In the moment, developers should be able to reassess priorities and make decisions accordingly. So it's unlikely, but there's a non-zero chance. Anything could happen. Verkl is not in Fusaka for now. And EOF in PeerDOS for now is in Fusaka. And there's a couple other EIPs that I think developers will reconsider for inclusion in Fusaka once developers have the bandwidth to really think about it and give their full attention to Fusaka after Pectra. These are some of the other ones that were considered for Pectra but never made it in. But now there's more time for these other code changes to be worked on. They could be a lot more ready for implementation six months from now than right now. So there's like the SSE transition, inclusion list, change to issuance. Everybody remember that debate? Could come back. History expiry, EPBS, and accounts traction, right? Like with the new transaction type, maybe there'll be some learnings from that, from Pectra, that inform next steps. So lots of other EIPs that could be included. The scoping discussion for Fusaka will be an interesting one to watch. So in the audience, I hope this just goes to show, please be engaged in Ethereum governance. I don't foresee, you know, very many upgrades left in Ethereum's future. So every upgrade counts and there's a lot of priorities on the list. And so it's worth it in the Ethereum ecosystem to make sure that your voice is heard and that decisions about where Ethereum protocol is heading is not made by like a few individuals or a few groups, but that the whole community and ecosystem gets involved. So thank you. I hope you learned something new about Ethereum and Pectra. Thank you. Thank you. Thank you, Christine. We have a couple, we have a few minutes for Q&A. As you can see, you can sort of upvote them there. So if you have one that you really want answered, please upvote right now. But I will let you take it away with when EOF. When EOF, I literally just said, the devs literally said that they are going to try and put it into Fusaka. Do I think that it's likely? Probably not. Do I think that Fusaka is going to happen in 2025? Absolutely not. I think that the amount of time is taken to prepare Pectra, Fusaka will take a similar, if not longer time. Awesome. And then if we want to answer, I think we have time for one more. Can you see them there? For us to increase blob target now in Pectra in case they get too expensive and so on. Yes, there definitely is an emergency path for increasing blob target. Oh, between now and Pektra activation. Hmm, no. Because blob target is a hard-coded target and max in the execution layer and consensus layer. For that to change, for blob capacity to change, developers need to do a hard fork. So no, I do not think that there's any way for the blob capacity to increase between now and Pektra without a hard fork. Yeah. Actually, we are doing okay on time. So we're going to keep cycling through these. Is the proposal to change the blob limit only or also the blob target? Okay. So that's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing the max at all. But that's not what layer two developers have asked for. There's this representative of the base team, a Coinbase's base team, and he's been vying for more aggressive increases. He's shown data to suggest that the increase wouldn't negatively impact the decentralization of Ethereum. So there's actually both. There's a conservative proposal to just change the target, and then there's a more ambitious proposal to change both the max and the target to like, it's like eight and four, if not like six and 12. So there's varying gradients. There's actually a lot of different ways in which devs could increase the target. We'll see how conservative they choose to go for, but yeah. And I think I'm going to go first. So you just urged people to be more involved in governance. We're going to jump to that question. How can the community get more involved in governance? Yes. Well, so ETH Research and ETH Magicians are two really great discussion forums for upvoting certain EIPs, showing your support for an EIP. I would say those are two really good ones. Another one that is good, but probably a little bit harder for everyone to do, if you have a representative from your company that wants to really advocate for an EIP, the ACD calls are probably the most high signal place to do it. All you have to do is just leave a comment on the ACD call agenda on GitHub and say, like, this is an EIP that I'd like to speak about or present. And the moderator of the call is usually very agreeable to giving you that time. Don't take up too much time, though, like maybe like five minutes, for you to say your piece. So use that chip sparingly, but that is probably one of the most...",
"eventId": "devcon-7",
- "slot_start": 1731643200000,
- "slot_end": 1731645000000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1b-4F9L2PRDflpHb2iAzeGwsuH6cvqfh3FMJsnOPZOtc"
+ "slot_start": 1731391200000,
+ "slot_end": 1731393000000,
+ "slot_roomId": "stage-1",
+ "resources_presentation": "https://docs.google.com/presentation/d/1aEeDer7GTTFvo4hdDKqx3zqCVAtFdk2XqVNuiRomMTc",
+ "resources_slides": null,
+ "speakers": [
+ "christine-kim"
+ ]
},
"vector": [
- 6,
- 0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -857977,8 +856151,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -858407,6 +856579,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -858520,6 +856693,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -858542,12 +856716,10 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -858560,44 +856732,46 @@
},
{
"session": {
- "id": "what-is-the-status-of-epbs-and-its-future-iterations",
- "sourceId": "3MUYVQ",
- "title": "What is the status of ePBS and its future iterations",
- "description": "We will go over the implementation and research status of ePBS (EIP-7732) and the future iterations and mechanisms it enables.We will describe in detail the main benefits to the protocol that are not directly related to any PBS system. We will showcase the tradeoffs that are present on each design decision and how the separation of validation between the consensus and execution layer in fact frees research with less technical debt and more independent mechanisms for future upgrades.",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "whats-in-your-dose",
+ "sourceId": "BRUGUL",
+ "title": "What's In Your Dose?",
+ "description": "Pandemic responses require robust technical tools such as molecular diagnostic tests, novel immunization reagents, and recovery surveillance tools. Pandemic responses depend on public trust in these tools and their good faith deployment. Verification strategies to enhance public trust and cooperation will improve the performance of molecular tools in future pandemics.",
+ "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "PBS",
- "consensus",
- "fork-choice"
+ "Molecular",
+ "Biology.",
+ "",
+ "Public",
+ "Health.",
+ "",
+ "Public",
+ "Trust."
],
"tags": [
- "PBS",
- "fork",
- "choice",
- "PBS"
+ "Decentralization",
+ "Public good"
],
"language": "en",
"speakers": [
- "potuz"
+ "phillip-j-buckhaults"
],
"eventId": "devcon-7",
- "slot_start": 1731472200000,
- "slot_end": 1731474000000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1hihFfnTMBS1Mmp0aS3oHwzA-PX43SVRFqlRfNkbtOwU"
+ "slot_start": 1731571500000,
+ "slot_end": 1731572400000,
+ "slot_roomId": "breakout-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1RgW3g8Dx3KqmsQIkx6vtDH-Q1Sykokl4An1TOH01ltI"
},
"vector": [
0,
+ 6,
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -859383,8 +857557,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -859446,12 +857618,14 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -859571,7 +857745,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -859887,7 +858060,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -859909,8 +858081,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -859927,45 +858099,41 @@
},
{
"session": {
- "id": "whats-going-into-the-pectra-upgrade",
- "sourceId": "9WTJRX",
- "title": "What’s Going Into the Pectra Upgrade?",
- "description": "A talk explaining the core EIPs going into the Pectra upgrade and the core EIPs still TBD for inclusion in Pectra. The talk will also touch on Pectra timing and fork scoping for the next hard fork after Pectra. Finally, the talk will share insights about the governance process of Ethereum in light of Pectra and takeaways about the priorities of Ethereum protocol developers.",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "white-rabbit-world-premiere",
+ "sourceId": "7CFGTS",
+ "title": "White Rabbit World Premiere",
+ "description": "White Rabbit is the first crowdfunded anime on Ethereum. It is about the metaphorical journey of going down the crypto rabbit hole. White Rabbit follows Mirai, who embarks on a path to discover the meaning of free will and self-sovereignty. There will be a seed phrase scavenger hunt in the final act of the film.\r\n\r\nDirected by pplpleasr and Maciej Kuciara, run time 30 minutes",
+ "track": "Entertainment",
+ "type": "Music",
"expertise": "Beginner",
- "audience": "Community",
- "featured": false,
+ "audience": "Design",
+ "featured": true,
"doNotRecord": false,
- "tags": [
- "fork",
- "hard"
- ],
"keywords": [
- "Pectra",
- "Governance",
- "Hard forks"
+ "animation",
+ "film",
+ "nft"
+ ],
+ "tags": [
+ "Account",
+ "Abstraction"
],
- "duration": 1515,
"language": "en",
- "sources_swarmHash": "9c19d1c251eda5ae03524a901f817d1fb823edb289430285e2f1c606f649b80f",
- "sources_youtubeId": "ufIDBCgdGwY",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f5e180d989c5b7ab5730.vtt",
- "transcript_text": " On what is going into the Pectra upgrade, we're going to talk about all the EOPs that are going into the Pectra upgrade. Quick disclaimer before I start, everything I'm about to say is all informational, for informational purposes, should not be construed as financial or investment advice. Before we get into what's going into Pectra, the question that I get asked the most is when Pectra is going on to mainnet. So I'm just going to get that out of the way so we can get into the technical stuff. This is a very tentative timeline analysis, and everyone's taking pictures already. When people ask me, when is Pectra going to happen? I say it's too early to tell because it's true. Pektra is still in very early stages of its development. Specifications are changing. The scope of Pektra even has not really truly been finalized quite yet, as we'll talk about. But through this process, one of the things that you can learn is how upgrades get developed, how upgrades get tested, and eventually make it onto main net. So initially what happens is developers decide on a couple of EIPs to include in an upgrade, and then they implement those EIPs onto private developer-focused test nets called DevNets. And developers have already launched a couple of DevNets already for Pektra, so these EIPs have already undergone a couple of rounds of implementation, and developers have noticed edge cases, have noticed various bugs that they want to fix, and they iterate. They iterate on these EIPs by launching new DevNets. DevNet 4 was launched last month, October. And this doesn't usually happen, but developers, very specially for this entire conference and for everybody in the audience, launched the first public Pektra testnet. This month, it's called Mekong. So you can go and interact with some of the EIPs that are going to be in Pektra early on. It's based on DevNet 4 specifications. But please note that those specifications are changing. There is a list of changes, specifications changes to the EIPs that developers already want to include into Pektra DevNet 5. So there's things like BLS precompile repricing, a new EIP that hasn't been implemented into DevNet 4, but developers are aiming to implement it in for DevNet 5 or a future upgrade. So Pektra specifications are changing. I foresee multiple more dev nets still to go before specifications can really be frozen. And the other part that's really important for the Pektra upgrade in its progress to mainnet is for the scope to be finalized. For all of the EIPs going into Pektra to be decided upon with developers. And there is one EIP. It's not really an EIP yet. But it's the blob capacity increase. That is what developers have not yet formally included into Pectra. But it seems as though they're likely to include a blob capacity increase, some kind of a blob capacity increase into Pectra because of the fact that they have recently included this EIP, which we're going to talk about, which introduces a mechanism to be able to update the blob gas target and the blob gas max dynamically through the consensus layer, rather than having those parameters hard coded in the execution layer and the consensus layer. So the addition of that mechanism into Pectra suggests that developers are doing all the heavy lifting of trying to implement a change to the blob capacity increase or a change to the blob capacity in Pektra. But developers have not formally decided or formally included that increase. Right now it's a target of three and a max of six. They're not sure if it's going to be an increase of four or five or six. So ideally, hopefully, developers will be able to finalize that early next year. And I think as the specifications for the other Pectra EIPs become hardened, more finalized, it puts pressure on developers to kind of activate them on main net. And in order to do that, you have to ensure that the scope of the upgrade is fully complete. So strong, I guess, like thinking or reasoning that the Pectra scope will be finalized by early next year. And then once it is finalized, you start testing whatever new EIPs that you've implemented, the full scope of the Pectra upgrade, you test that and battle test it on a couple more DevNets. I envision, say, you know, until maybe DevNet 6 or 7. And then once the Pectra specifications are frozen, they are ready to go, all the edge cases that developers can find on DevNets have been found, they will then release the Pektra specifications, developers have budgeted about two weeks between public testnet upgrades. In kind of rare occasions, developers kind of shrunk that timeline down to even just one week between testnets. But because of the size of Pectra, I imagine that developers will want to take the full time to see how the Pectra upgrade fares on public testnet environments. So I am budgeting roughly about a month for the Sepolia and the Holesky. Holesky, I don't even know how you say it right, but Holesky. Thank you, sir. Yeah, so that's going to happen. And I'm budgeting about a month for that. And then after, that's when you can finally have the mainnet activation. So given all of the information that I know right now and the progress that developers have made so far on Pectra, my best analysis and guess is that Pectra mainnet will realistically happen next April 2025. Again, this is very tentative because a lot can change between now and April. Development happens on a week-to-week basis. Developers are on these ACD calls talking about this bug that they didn't expect in this EIP. Or this new EIP that they do want to add into Pektra now. So a lot of things can change this timeline. But looking into my crystal ball, there you have it, my timeline. Let's move on to what is the meat, you know, the bread and butter of this talk, which is what is going into the Pectra upgrade. There are 10 EIPs that are going into Pectra. And four of them are focused on the execution layer. Oh, my gosh, the print is so small there. EIP-2537. It is a new precompile. Yay. a new precompile, yay, new precompile into the EVM, BLS12381 curve operation. This is a new cryptographic signature scheme that smart contract developers have been asking for for a very long time. This is an EAP that was created in 2020. And at the time, dApp developers were like, we really want this because it would give dApps, certain dApps that are relying on zero knowledge cryptography, stronger privacy guarantees, potentially increased security and scalability. I believe BLS signatures, that signature scheme or that aggregation is also the signature aggregation that happens on the consensus layer for validator attestations. This EIP is a long time coming. And so I think one of the concerns around this EIP is, are there still apps that are waiting for the BLS precompile? And are they going to use it when that precompile goes live? So kind of an open question. But if you're in this audience and didn't know that the BLS precompile is finally coming, it's coming. And maybe, you know, you have an app that hasn't already moved on from this vision and can still utilize this precompile in some pretty cool ways. So it's going into Pectra. EIP-2935 serve historical block hashes from state. This one introduces a change to the execution layer such that proofs of historical blocks can be generated from the state. This does have some near-term benefits. So it has some benefits for light client syncing, has some benefits for smart contracts that may want to utilize data about the state of a prior block directly through the EVM. You can't actually do that right now. But those near-term benefits is not the reason that this EIP was included into Pektra. Because clearly those benefits are a little bit iffy. Not like super important, I guess. But the main reason why that was included into Pektra is because it's a prerequisite for Verkl. And Verkl is this major overhaul to Ethereum's structure for state data on Ethereum. That developers had thought that transition was going to happen right after Pektra. So they're like, oh, you know, Fusaka, this is when Verkl's going to happen. Oh, well, we need this EAP if we're going to do that Verkl transition. But turns out, as we're going to talk later in this presentation, Verkl's not going to go into Fusaka, or at least that's not what developers are expecting right now. They've punted it out to another upgrade. But it's still there. Developers did implement it and it will have some near-term benefits. But the primary reason for it is as a prerequisite to Verkl, which, you know, could happen down the road. And if it does, you know, this stepping stone has already been checked off the list. EIP-7685, general purpose execution layer requests. This is an EIP that doesn't really introduce new features to Ethereum. It's really an EIP to support other EIPs in Pectra. So in Pectra, there's a couple of other EIPs where the execution layer will be able to pass way more messages, different kinds of messages to the consensus layer that it couldn't before. The execution layer, smart contracts on the execution layer will be able to trigger like validator withdrawals, consolidations, deposits. And rather than implementing these new messages, these new communication channels, all in a separate kind of unique fashion, the implementation of these generalized, these execution layer triggerable requests, the implementation of all these requests, instead of doing it in kind of like a siloed fashion, why not create like a generalized structure, a generalized bus to house these requests? It will be easier to test, easier to implement across clients, easier to kind of standardize, especially if developers want to introduce new types of execution layer triggerable requests. So Geth developer, like client, he was like, I think this would be a good EIP to add. Once developers started implementing those other EIPs, they're like, oh, actually, this is something that would be pretty useful. So that's why EIP 7685 is in there, an EIP to support the other EIPs. EIP 7702, this one's kind of, I guess, an exciting one. A new transaction type is coming into Ethereum, and this transaction type is going to temporarily allow a user-controlled account, an EOA, externally owned account, to have greater flexibility and enable features like some that I think many people in the audience have been waiting for for a while, to enable EOAs to have features like transaction batching, sponsored transactions, conditional transactions, delegated security. Pretty cool stuff. Like you're thinking, oh my gosh, is this like the account abstraction vision coming alive on Ethereum? No, it's not. It's a baby step. So it's kind of like a baby step to seeing how this will improve the user experience. It is cool that some kind of temporary functionality that you'll be able to create some kind of temporary new flexibility into EOAs. But really it's an early step to see what the real roadmap to true native account abstraction could look like on Ethereum. This had quite a bit of debate in terms of how developers should take that first step. A lot of controversy of this one getting in and its design. But it's in there. And I'm pretty sure of all the EIPs that developers want you to interact with and kind of test on the Mekong testnet, this is probably high up on the list. You know, trying out this new transaction type. So if you're on Mekong, you know, throw developers a bone. Try it out. There are six others. These ones are consensus layer EIPs. I'm going to run through these really quickly. Because after me there's going to be some talks that go deeper into each of these EIPs. So this is just, you know, summary overview. EIP 7742 uncoupled blob count between the consensus layer and the execution layer. This one is the most recent EIP to be included into Pectra. Developers, like I said, was considering should we include an increase to the blob capacity? And if we're going to do that, currently the blob capacity is hard-coded into the execution layer and the consensus layer. And the hard-coding of these constants are all kind of different in all the clients. And so updating that hard coding is not as easy as some may think. So creating a mechanism to kind of be able to change the blob capacity and have it dynamically set by the consensus layer will ensure that in the future developers can easily change the blob capacity of Ethereum if they want to. And ensure that that kind of upgrade, it only requires consensus layer changes, doesn't require a change to both the execution layer and the consensus layer. So, yeah. But it's like heavy work up front, right? Because the mechanism doesn't exist right now. Once the mechanism exists, yes, it will be easy to use that mechanism increase, the blob capacity in Pectra, we should really get started on this mechanism sooner rather than later. And so developers were like, actually, yes, other developers on the call, on the ACD calls I'm talking about. They're like, you know what, that's probably a good idea. So that's why it was included. Developers have not decided on what specifically that increase is going to be quite yet. Let's dive deeper into some of these other ones. EIP6110, supply to validate deposits on chain. Vitalik, he was like, woohoo, in the main stage talk, like the merge happened. The merge did happen. And Ethereum is more mature as a proof of stake blockchain. There are certain security assumptions that can be relaxed now. And one of those security assumptions is an additional round of voting that happens every time you deposit a 32 ETH on the Ethereum 2.0 deposit contract. There's an additional round of voting that happens on the consensus layer side to verify those deposits. This EIP removes that additional round of voting on the consensus layer side, ensures all the deposit validation happens on the consensus layer side ensures all the deposit validation happens on the execution layer. This has some benefits for validator UX. It will shrink the time between when you deposit your 32 ETH and when you see the validator actually be activated on the beacon chain. EIP7002, execution layer triggerable withdrawals. This is very good for staking pools. Right now, validators, if you want to fully withdraw a validator, the node operator that controls, that operates that validator needs to withdraw, they need to use their withdrawal key to fully exit the validator. But through the CIP, smart contracts will be able to initiate those full withdrawals. So it's kind of a trust assumption that you can now remove from staking pools. The likes of, say, like Lido, Rocket Pool, other smart contract-based staking pools, you can ‑‑ those smart contracts can now trigger full withdrawals of validators if they wish. So a very nice feature for trustlessness and improving the, yes, I don't know, like resiliency, yes, resiliency of smart contract-based staking pools. EIP-7251, increasing the maximum effective balance. I have written so many reports on the problem of Ethereum's growing validator set size. This really is an issue. I guess, you know, when developers were thinking about the beacon chain, they did not expect the validator set to grow so quickly and for the peer-to-peer network of Ethereum not to be able to handle 1.5 million validators. I think we're at like 1.2 or 1.3. Somebody can check me on that. But there's a lot of validators, a lot of active validators, a lot of messages being passed around on the networking layer, and it's too much. It really is too much. So it's straining nodes, and left unchecked, it would be a major problem for the health of Ethereum. So EIP-7251 is designed to encourage validators to consolidate their ETH and have a maximum effective balance higher than 32 ETH and reduce the number of active validators on Ethereum. That is the goal of EIP-7251. Let's see how quickly it is adopted once Pectra goes live because that, you know, depends on all of the staking pools and stakeholders of the staking community really, you know, getting it together, okay? So EIP-7549, move committee index outside attestation, kind of like a restructuring, refactoring of the way that attestations are aggregated to make blocks, or to reduce the networking load of Ethereum. Again, see, there's clearly networking pains, and save node bandwidth. And kind of a quick note about the CIP, developers when they were including it in Pektra, this is a great change, clearly has wonderful benefits, an easy one to go ahead with. In practice, though, turned out to be a lot harder to implement than expected. So sometimes that's the way the cookie crumbles. Wow. I cannot believe I only have two more minutes. Okay. So in like the outlook, if you know, I blazed through that really fast. Don't worry. In summary, Petra is a mixed bag of updates. It's going to do three things. It's going to fix critical shortcomings of Ethereum as a proof of stake blockchain. Think about max EB, right? Like that's a critical fix that needs to happen because the validator set size can continue to grow unchecked. Improve the user experience, right? We're talking about, like, the new transaction type, making it always more flexible, some improvements for more trustless designs for staking pools, etc. Some minor UX improvements there. And number three, Ethereum's data availability capacity, increasing that. That hasn't been formally included into Pectra, but again, seems likely. Moving on. Okay, here are all the EIPs that were removed from Pectra. This is kind of like a first-time thing for an upgrade to have so many EIPs removed from it. The first one is PeerDAS. Honestly, there was going to be a much bigger increase to data availability capacity in Pectra. Initially, when Pectra was being scoped out, PeerDAS is going to allow developers to increase the blob target of Ethereum, not from like three to four to like four to five, but like by multiples more without impacting greatly the bandwidth consumption and the computational requirements of running an Ethereum node. But it's still in research and development phase. It's still being developed. And these other 11 code changes as a bundle are called EOF. It's this major update to the Ethereum EVM. And both of these EIPs, all these EIPs were initially included in Pectra, but they were being tested on separate devnets. So you had the Pectra EIPs that were moving along, progressing, starting to solidify, starting to become more aspects of it were starting to become more or less finalized. But PeerDAS and EOF, there were developers thought that it would require a lot more time to get them really ready for mainnet activation, and developers did not want to delay the activation of the Pektra EIPs from getting onto mainnet, which is why one of the reasons was they wanted to get Pectra EIPs out sooner. So they said PeerDAS and EOF clearly needs more time to be worked on. We'll pump that to another upgrade and not hold back these other Pectra EIPs from mainnet. Another reason is this is a lot of EIPs in addition to the other ten that I talked about, so lots of risk, right? With the interdependencies of the code, trying to implement it all at once. This is a lot of work and time for the testing team and the client teams to be able to ensure there aren't any bugs. So lots of reasons for two, I would say, actually main reasons for why these EIPs were removed from Pectra. And now they are moved to Fusaka. So again, I have Verkl up there because Verkl was initially slated for Fusaka, but then now it's not going to because developers have given a soft confirmation that EOF and PeerDAS are going to be in Fusaka. But again, obviously, changes happen. In the moment, developers should be able to reassess priorities and make decisions accordingly. So it's unlikely, but there's a non-zero chance. Anything could happen. Verkl is not in Fusaka for now. And EOF in PeerDOS for now is in Fusaka. And there's a couple other EIPs that I think developers will reconsider for inclusion in Fusaka once developers have the bandwidth to really think about it and give their full attention to Fusaka after Pectra. These are some of the other ones that were considered for Pectra but never made it in. But now there's more time for these other code changes to be worked on. They could be a lot more ready for implementation six months from now than right now. So there's like the SSE transition, inclusion list, change to issuance. Everybody remember that debate? Could come back. History expiry, EPBS, and accounts traction, right? Like with the new transaction type, maybe there'll be some learnings from that, from Pectra, that inform next steps. So lots of other EIPs that could be included. The scoping discussion for Fusaka will be an interesting one to watch. So in the audience, I hope this just goes to show, please be engaged in Ethereum governance. I don't foresee, you know, very many upgrades left in Ethereum's future. So every upgrade counts and there's a lot of priorities on the list. And so it's worth it in the Ethereum ecosystem to make sure that your voice is heard and that decisions about where Ethereum protocol is heading is not made by like a few individuals or a few groups, but that the whole community and ecosystem gets involved. So thank you. I hope you learned something new about Ethereum and Pectra. Thank you. Thank you. Thank you, Christine. We have a couple, we have a few minutes for Q&A. As you can see, you can sort of upvote them there. So if you have one that you really want answered, please upvote right now. But I will let you take it away with when EOF. When EOF, I literally just said, the devs literally said that they are going to try and put it into Fusaka. Do I think that it's likely? Probably not. Do I think that Fusaka is going to happen in 2025? Absolutely not. I think that the amount of time is taken to prepare Pectra, Fusaka will take a similar, if not longer time. Awesome. And then if we want to answer, I think we have time for one more. Can you see them there? For us to increase blob target now in Pectra in case they get too expensive and so on. Yes, there definitely is an emergency path for increasing blob target. Oh, between now and Pektra activation. Hmm, no. Because blob target is a hard-coded target and max in the execution layer and consensus layer. For that to change, for blob capacity to change, developers need to do a hard fork. So no, I do not think that there's any way for the blob capacity to increase between now and Pektra without a hard fork. Yeah. Actually, we are doing okay on time. So we're going to keep cycling through these. Is the proposal to change the blob limit only or also the blob target? Okay. So that's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing's a great question. Blob target, the most conservative increase is three to four, just changing the target, not changing the max at all. But that's not what layer two developers have asked for. There's this representative of the base team, a Coinbase's base team, and he's been vying for more aggressive increases. He's shown data to suggest that the increase wouldn't negatively impact the decentralization of Ethereum. So there's actually both. There's a conservative proposal to just change the target, and then there's a more ambitious proposal to change both the max and the target to like, it's like eight and four, if not like six and 12. So there's varying gradients. There's actually a lot of different ways in which devs could increase the target. We'll see how conservative they choose to go for, but yeah. And I think I'm going to go first. So you just urged people to be more involved in governance. We're going to jump to that question. How can the community get more involved in governance? Yes. Well, so ETH Research and ETH Magicians are two really great discussion forums for upvoting certain EIPs, showing your support for an EIP. I would say those are two really good ones. Another one that is good, but probably a little bit harder for everyone to do, if you have a representative from your company that wants to really advocate for an EIP, the ACD calls are probably the most high signal place to do it. All you have to do is just leave a comment on the ACD call agenda on GitHub and say, like, this is an EIP that I'd like to speak about or present. And the moderator of the call is usually very agreeable to giving you that time. Don't take up too much time, though, like maybe like five minutes, for you to say your piece. So use that chip sparingly, but that is probably one of the most...",
- "eventId": "devcon-7",
- "slot_start": 1731391200000,
- "slot_end": 1731393000000,
- "slot_roomId": "stage-1",
- "resources_presentation": "https://docs.google.com/presentation/d/1aEeDer7GTTFvo4hdDKqx3zqCVAtFdk2XqVNuiRomMTc",
- "resources_slides": null,
"speakers": [
- "christine-kim"
- ]
+ "pplpleasr"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731497400000,
+ "slot_end": 1731500100000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1IhRTtp7JRxxcgFhG5DluJWQD1KNt28d8UsxmQ7icfhc"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -860688,13 +858856,29 @@
0,
0,
0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -860945,29 +859129,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -861263,8 +859424,7 @@
0,
0,
2,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -861288,56 +859448,67 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
0,
+ 2,
0,
0
]
},
{
"session": {
- "id": "whats-in-your-dose",
- "sourceId": "BRUGUL",
- "title": "What's In Your Dose?",
- "description": "Pandemic responses require robust technical tools such as molecular diagnostic tests, novel immunization reagents, and recovery surveillance tools. Pandemic responses depend on public trust in these tools and their good faith deployment. Verification strategies to enhance public trust and cooperation will improve the performance of molecular tools in future pandemics.",
- "track": "[CLS] d/acc Discovery Day: Building Towards a Resilient Utopia",
+ "id": "who-needs-a-wallet-anyway",
+ "sourceId": "ZZKKRZ",
+ "title": "Who needs a wallet anyway?",
+ "description": "This talk confronts the community’s obsession with decentralization purity at the cost of usability. This session explores how to hide the complexities of crypto, enabling seamless integration for users who may not even realize they are using a wallet. We’ll cover simplifying user interactions, making wallets function invisibly, maintaining benefits like permissionless innovation, managing thousands of wallets, and real-world applications. It’s time to push for real, user-friendly innovation.",
+ "track": "Usability",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "expertise": "Beginner",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Molecular",
- "Biology.",
- "",
- "Public",
- "Health.",
- "",
- "Public",
- "Trust."
- ],
"tags": [
+ "Permissionless",
+ "Developer Infrastructure",
"Decentralization",
- "Public good"
+ "Environment",
+ "User Experience",
+ "trusted",
+ "wallet",
+ "execution",
+ "Developer Infrastructure",
+ "Permissionless",
+ "User Experience"
],
- "language": "en",
- "speakers": [
- "phillip-j-buckhaults"
+ "keywords": [
+ "Trusted",
+ "Execution",
+ "Environments"
],
+ "duration": 555,
+ "language": "en",
+ "sources_swarmHash": "dcba0214c791f887977ae84378b09be85862162e256dc4fea0db787f53e98d83",
+ "sources_youtubeId": "iNLHWc5toYo",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330c253a168eb535efb410.vtt",
+ "transcript_text": " Hey, everyone. How's it going? Good? Bad? Terrible? Everything good? Okay. So I'm Itai, co-founder of Dynamic. And what I want to talk to you guys today about is pretty much who needs a wallet anyway. Just a raise of hands, who has heard a wallet talk today before my talk? Or is this the first talk of wallets anyway? No? Okay. So let's start. So a little bit about me and Shameless Plug. So I'm the co-founder and CEO of Dynamic. We essentially do everything that has to do with email login, social login, wallet login on a site. So when you click login, if you go to Magic Eden today or Doodles or Pudgy Penguin and you click login, that's probably powered by Dynamic. We help you build crypto-enabled experiences. But that's pretty much all I'll kind of shamelessly plug about Dynamic. Again, we're powering a bunch of these popular apps. That's just context for why I'm talking about this topic, which is the topic of wallets or abstraction of those wallets. So let's get to it. So at the very basic level, the web is moving to a wallet-based world, right? If you open your phone in five years and look at every app on your phone, it's likely going to have a wallet component to it. It's a very effective way to transfer money, to transfer assets, to kind of control it. It's a very effective way to transfer money, to transfer assets, to kind of control identity. It's a really, really cool way. And what we're seeing is that we're starting to see apps on your phone, not new apps, but existing apps, have wallet components to them. But users don't really care about wallets. No one wakes up in the morning and says, I really want a wallet, right? You want these like magical experiences. And when they're crypto enabled, you kind of need a wallet to enable them. Wallets are not the star of the show. It pains me to say as a wallet company, but we are not the stars of the show. We're pretty much kind of in the background infrastructure. And so the way to think about wallets is really in an analogy of thinking about crypto as the electric grid, as power. And everyone wants to kind of hook up to power. Wallets are really outlets in your wall. We're in the business of selling outlets to you. And those, no one kind of cares about outlets. Outlets are not kind of the thing you buy for the sake of buying outlets. You buy them because you want to plug in your TV and watch TV or you want to plug in your laptop and kind of play games. Right? So wallets aren't the main part of the show. So why are we putting wallets front and center today? Why are there so many branded wallets? Why are we even talking about them? And the answer is we shouldn't. Right? People don't care. Maybe folks in this room do, but anyone else doesn't really care about wallets, right? And that's exactly what we're seeing in this market. And so what I want to show you is two examples of companies that are abstracting away wallets and deferring that to later on in the process and focusing on building these magical consumer experiences where wallets don't kind of come up front and center, where you don't log in with a wallet first. And one example, let's see if this video works. Oh, I actually did. Okay, that's, uh, that's great. Uh, so this is a company called Dflow and, uh, it lets you trade pretty much anything you want. You log in with email, you enter your passcode, and at that point you're done, right? So we'll see whether this enters it. Bear with me for a second. Oh, okay, great. The video actually works. So I entered an email, I logged in and I'm done. At this point, I have a wallet. I can kind of export my private key. It's a non-custodial wallet. I can trade, but I really don't need to care about the fact that I have a wallet. It's my way of accessing crypto without really knowing it's crypto. In the same example, there's a really cool app out there. Let's see if this works. Bear with me for a second. It actually did. Called Bags. Who's used Bags before? Love it. Okay, so it's a really cool app. The idea is, again, it's a't really care about the fact that you have a wallet. It's just a means to an end, right? But the challenge with that and the challenge of what I've shown is that while we're seeing this daily across everything, whether it's Deepin or RWA, et cetera, the challenge is that it kind of optimizes for local maxima, right? It optimizes for we're going to have hundreds of wallets, right? We solve the new user onboarding problem, but we don't solve the interoperability problem, right? We optimize kind of each one of these app optimizes for them. It doesn't optimize for kind of a global, really nice, hey, everything is in a single wallet. But we can actually optimize. And this is the only technical slide, apologies. But my point here is to say that everything we're seeing in this market, everything that we're seeing with hundreds of these wallets be generated across these apps, that's totally fine. Because what will happen is providers like us and others will start thinking about ways to let you aggregate those across different kind of apps. So you start with a local maxima. You start by kind of letting someone accomplish what they want to accomplish, and then you start building tools to let them aggregate these magical wallets. And so I'm actually good on time, which is surprising, but my main takeaway from this talk, and I know it's a very quick talk, but my main takeaway, if you take nothing else away, is as you see these embedded wallets, as you see these hundreds of apps or thousands of new social apps or DeFi apps or DePay apps come up and they don't talk about wallets and you're worried about, hey, I'm going to start having these hundreds of wallets with all my assets distributed across them in my pocket, know that it's fine. It's a step in the path to kind of these global decentralization type standards. And not all hope is lost. So what we'll see in a couple years is we'll see these kind of apps, excuse me, consolidate into this kind of magical branded wallets that let you kind of connect these small accounts that you generated into bigger ones. So the future is not lost. Hopefully everyone comes out of this kind of encouraged that it's a step abstracting away wallets is a step towards kind of a really nice crypto future without jeopardizing onboarding experience in the short term. And with that, if anyone wants to talk to me about it, if anyone wants to tell me, I have no idea what I'm talking about, just here's my telegram. It's ping me. You can email me at Itai at dynamic.xyz and I would love to take questions. Awesome. Thank you so much man. Who's got a question? Who's got a question for Itai at this moment? We have just room for one question so who's going to be the lucky one? Going once. Here please. Go for it. What are the security concerns with this parent-child wallet relationship? Yeah, the short answer is a bunch, right? The longer answer is that not all your wallets actually need to be connected over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the single identity, but we're actually creatures of multiple identities, right? I have my identity at home with my kids, I have my identity at work, I have my gaming identity, I have my social identity, and they're different. And you might actually not have this one parent-child, but you might have multiple parents depending on your identity. So that's one way to de-risk it. The second is about controls, just like everything else here. It's about the beauty of optionality, which is at times you can one-click unlink, you can one-click link, you can consolidate your assets, you can break them up. And so it's about optionality and kind of the ability for you to create multiple identities that kind of lower the security risk. But the short answer to your question is, just like anything else, when you combine multiple wallets into a single place, you create some security risk. And I think that's all the time we had, right? How am I doing? One more question. One quick question. Do quick question. There's one in the thing. Oh, yeah, go for it. Do you pass key integrations? Okay. I'm going to make a bet on what this question means. Do we offer pass key integrations? The answer is yes, we do. Whether that was the question or not, I don't care. The answer I want to give is yes, we do. We actually offer passASC integrations. PASCs are, in general, this really magical thing because they're a private public key on your phone and they inherit some really cool properties with companies like Google and Apple that while we sometimes don't like, they kind of have to deal with security, to your point, at the state actor level. And so they really have to think about this stuff at really massive scale, and PASCIs are one of the outputs of that thinking. And so, yes, we specifically offer PASCI integrations. I'm sure others within our industry do as well. They're a really powerful tool to actually get to this both non-custody or self-custody as well as create this experience that at least on mobile, feels very native, which is a face ID type experience. So yes, short answer is yes. Thank you so much, Itayi. That was fantastic. Please give him a great applause. Thanks, everyone. Appreciate it.",
"eventId": "devcon-7",
- "slot_start": 1731571500000,
- "slot_end": 1731572400000,
- "slot_roomId": "breakout-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1RgW3g8Dx3KqmsQIkx6vtDH-Q1Sykokl4An1TOH01ltI"
+ "slot_start": 1731393600000,
+ "slot_end": 1731394200000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1pVk3HgI3jY_eVj3C7F4jVkcdwrwbVFi9NzWDCgBBUFg",
+ "resources_slides": null,
+ "speakers": [
+ "itai-turbahn"
+ ]
},
"vector": [
- 0,
- 6,
0,
0,
0,
@@ -861346,6 +859517,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -862102,6 +860274,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -862139,10 +860312,7 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
+ 2,
0,
0,
0,
@@ -862197,9 +860367,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -862263,6 +860430,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -862285,6 +860453,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -862353,6 +860522,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -862453,6 +860623,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -862601,6 +860772,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -862651,9 +860823,6 @@
0,
2,
0,
- 0,
- 0,
- 0,
2,
0,
0,
@@ -862666,43 +860835,46 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "white-rabbit-world-premiere",
- "sourceId": "7CFGTS",
- "title": "White Rabbit World Premiere",
- "description": "White Rabbit is the first crowdfunded anime on Ethereum. It is about the metaphorical journey of going down the crypto rabbit hole. White Rabbit follows Mirai, who embarks on a path to discover the meaning of free will and self-sovereignty. There will be a seed phrase scavenger hunt in the final act of the film.\r\n\r\nDirected by pplpleasr and Maciej Kuciara, run time 30 minutes",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "Beginner",
- "audience": "Design",
- "featured": true,
+ "id": "who-wins-ethereum-block-building-auctions-and-why",
+ "sourceId": "VKQ8NC",
+ "title": "Who Wins Ethereum Block Building Auctions and Why?",
+ "description": "Today, top 3 block builders produce over 90% of blocks on Ethereum via MEV-boost auction. The block builder market's dynamics evolve rapidly and has significant impact on the development of private mempools, wallets/apps orderflow auctions, and censorship resistance topic. In this talk, we share an overview of why the top builders win the most market share, using orderflow composition and bidding behavioral data. We hope to highlight the centralizing risks and failures of current market design.",
+ "track": "Cryptoeconomics",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Research",
+ "featured": false,
"doNotRecord": false,
"keywords": [
- "animation",
- "film",
- "nft"
+ "MEV",
+ "PBS",
+ "Block Auction"
],
"tags": [
- "Account",
- "Abstraction"
+ "blocks",
+ "auction"
],
"language": "en",
"speakers": [
- "pplpleasr"
+ "danning-sui",
+ "burak-oz"
],
"eventId": "devcon-7",
- "slot_start": 1731497400000,
- "slot_end": 1731500100000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1IhRTtp7JRxxcgFhG5DluJWQD1KNt28d8UsxmQ7icfhc"
+ "slot_start": 1731558600000,
+ "slot_end": 1731560400000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1sCbCcL_kcX8oEU3I_BJLpuFgt1wzgpYDENnympxQ7iI"
},
"vector": [
0,
0,
+ 6,
0,
0,
0,
@@ -862710,8 +860882,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -863432,6 +861602,7 @@
0,
0,
6,
+ 6,
0,
0,
0,
@@ -863597,6 +861768,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -863776,6 +861948,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -863998,9 +862171,6 @@
0,
0,
0,
- 2,
- 2,
- 0,
0,
0,
0,
@@ -864012,6 +862182,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -864028,60 +862199,35 @@
0,
0,
0,
- 0,
- 2,
- 0,
0
]
},
{
"session": {
- "id": "who-needs-a-wallet-anyway",
- "sourceId": "ZZKKRZ",
- "title": "Who needs a wallet anyway?",
- "description": "This talk confronts the community’s obsession with decentralization purity at the cost of usability. This session explores how to hide the complexities of crypto, enabling seamless integration for users who may not even realize they are using a wallet. We’ll cover simplifying user interactions, making wallets function invisibly, maintaining benefits like permissionless innovation, managing thousands of wallets, and real-world applications. It’s time to push for real, user-friendly innovation.",
- "track": "Usability",
- "type": "Lightning Talk",
- "expertise": "Beginner",
+ "id": "why-defi-matters-on-ethereum",
+ "sourceId": "E7GFJC",
+ "title": "Why DeFi matters on Ethereum",
+ "description": "Why DeFi matters on Ethereum, and why Ethereum is the best place for DeFi.",
+ "track": "Real World Ethereum",
+ "type": "Panel",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "Permissionless",
- "Developer Infrastructure",
- "Decentralization",
- "Environment",
- "User Experience",
- "trusted",
- "wallet",
- "execution",
- "Developer Infrastructure",
- "Permissionless",
- "User Experience"
- ],
- "keywords": [
- "Trusted",
- "Execution",
- "Environments"
- ],
- "duration": 555,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "dcba0214c791f887977ae84378b09be85862162e256dc4fea0db787f53e98d83",
- "sources_youtubeId": "iNLHWc5toYo",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67330c253a168eb535efb410.vtt",
- "transcript_text": " Hey, everyone. How's it going? Good? Bad? Terrible? Everything good? Okay. So I'm Itai, co-founder of Dynamic. And what I want to talk to you guys today about is pretty much who needs a wallet anyway. Just a raise of hands, who has heard a wallet talk today before my talk? Or is this the first talk of wallets anyway? No? Okay. So let's start. So a little bit about me and Shameless Plug. So I'm the co-founder and CEO of Dynamic. We essentially do everything that has to do with email login, social login, wallet login on a site. So when you click login, if you go to Magic Eden today or Doodles or Pudgy Penguin and you click login, that's probably powered by Dynamic. We help you build crypto-enabled experiences. But that's pretty much all I'll kind of shamelessly plug about Dynamic. Again, we're powering a bunch of these popular apps. That's just context for why I'm talking about this topic, which is the topic of wallets or abstraction of those wallets. So let's get to it. So at the very basic level, the web is moving to a wallet-based world, right? If you open your phone in five years and look at every app on your phone, it's likely going to have a wallet component to it. It's a very effective way to transfer money, to transfer assets, to kind of control it. It's a very effective way to transfer money, to transfer assets, to kind of control identity. It's a really, really cool way. And what we're seeing is that we're starting to see apps on your phone, not new apps, but existing apps, have wallet components to them. But users don't really care about wallets. No one wakes up in the morning and says, I really want a wallet, right? You want these like magical experiences. And when they're crypto enabled, you kind of need a wallet to enable them. Wallets are not the star of the show. It pains me to say as a wallet company, but we are not the stars of the show. We're pretty much kind of in the background infrastructure. And so the way to think about wallets is really in an analogy of thinking about crypto as the electric grid, as power. And everyone wants to kind of hook up to power. Wallets are really outlets in your wall. We're in the business of selling outlets to you. And those, no one kind of cares about outlets. Outlets are not kind of the thing you buy for the sake of buying outlets. You buy them because you want to plug in your TV and watch TV or you want to plug in your laptop and kind of play games. Right? So wallets aren't the main part of the show. So why are we putting wallets front and center today? Why are there so many branded wallets? Why are we even talking about them? And the answer is we shouldn't. Right? People don't care. Maybe folks in this room do, but anyone else doesn't really care about wallets, right? And that's exactly what we're seeing in this market. And so what I want to show you is two examples of companies that are abstracting away wallets and deferring that to later on in the process and focusing on building these magical consumer experiences where wallets don't kind of come up front and center, where you don't log in with a wallet first. And one example, let's see if this video works. Oh, I actually did. Okay, that's, uh, that's great. Uh, so this is a company called Dflow and, uh, it lets you trade pretty much anything you want. You log in with email, you enter your passcode, and at that point you're done, right? So we'll see whether this enters it. Bear with me for a second. Oh, okay, great. The video actually works. So I entered an email, I logged in and I'm done. At this point, I have a wallet. I can kind of export my private key. It's a non-custodial wallet. I can trade, but I really don't need to care about the fact that I have a wallet. It's my way of accessing crypto without really knowing it's crypto. In the same example, there's a really cool app out there. Let's see if this works. Bear with me for a second. It actually did. Called Bags. Who's used Bags before? Love it. Okay, so it's a really cool app. The idea is, again, it's a't really care about the fact that you have a wallet. It's just a means to an end, right? But the challenge with that and the challenge of what I've shown is that while we're seeing this daily across everything, whether it's Deepin or RWA, et cetera, the challenge is that it kind of optimizes for local maxima, right? It optimizes for we're going to have hundreds of wallets, right? We solve the new user onboarding problem, but we don't solve the interoperability problem, right? We optimize kind of each one of these app optimizes for them. It doesn't optimize for kind of a global, really nice, hey, everything is in a single wallet. But we can actually optimize. And this is the only technical slide, apologies. But my point here is to say that everything we're seeing in this market, everything that we're seeing with hundreds of these wallets be generated across these apps, that's totally fine. Because what will happen is providers like us and others will start thinking about ways to let you aggregate those across different kind of apps. So you start with a local maxima. You start by kind of letting someone accomplish what they want to accomplish, and then you start building tools to let them aggregate these magical wallets. And so I'm actually good on time, which is surprising, but my main takeaway from this talk, and I know it's a very quick talk, but my main takeaway, if you take nothing else away, is as you see these embedded wallets, as you see these hundreds of apps or thousands of new social apps or DeFi apps or DePay apps come up and they don't talk about wallets and you're worried about, hey, I'm going to start having these hundreds of wallets with all my assets distributed across them in my pocket, know that it's fine. It's a step in the path to kind of these global decentralization type standards. And not all hope is lost. So what we'll see in a couple years is we'll see these kind of apps, excuse me, consolidate into this kind of magical branded wallets that let you kind of connect these small accounts that you generated into bigger ones. So the future is not lost. Hopefully everyone comes out of this kind of encouraged that it's a step abstracting away wallets is a step towards kind of a really nice crypto future without jeopardizing onboarding experience in the short term. And with that, if anyone wants to talk to me about it, if anyone wants to tell me, I have no idea what I'm talking about, just here's my telegram. It's ping me. You can email me at Itai at dynamic.xyz and I would love to take questions. Awesome. Thank you so much man. Who's got a question? Who's got a question for Itai at this moment? We have just room for one question so who's going to be the lucky one? Going once. Here please. Go for it. What are the security concerns with this parent-child wallet relationship? Yeah, the short answer is a bunch, right? The longer answer is that not all your wallets actually need to be connected over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the over time, right? We think about this connection of parent-child and kind of a general account and sub-account as required to create the single identity, but we're actually creatures of multiple identities, right? I have my identity at home with my kids, I have my identity at work, I have my gaming identity, I have my social identity, and they're different. And you might actually not have this one parent-child, but you might have multiple parents depending on your identity. So that's one way to de-risk it. The second is about controls, just like everything else here. It's about the beauty of optionality, which is at times you can one-click unlink, you can one-click link, you can consolidate your assets, you can break them up. And so it's about optionality and kind of the ability for you to create multiple identities that kind of lower the security risk. But the short answer to your question is, just like anything else, when you combine multiple wallets into a single place, you create some security risk. And I think that's all the time we had, right? How am I doing? One more question. One quick question. Do quick question. There's one in the thing. Oh, yeah, go for it. Do you pass key integrations? Okay. I'm going to make a bet on what this question means. Do we offer pass key integrations? The answer is yes, we do. Whether that was the question or not, I don't care. The answer I want to give is yes, we do. We actually offer passASC integrations. PASCs are, in general, this really magical thing because they're a private public key on your phone and they inherit some really cool properties with companies like Google and Apple that while we sometimes don't like, they kind of have to deal with security, to your point, at the state actor level. And so they really have to think about this stuff at really massive scale, and PASCIs are one of the outputs of that thinking. And so, yes, we specifically offer PASCI integrations. I'm sure others within our industry do as well. They're a really powerful tool to actually get to this both non-custody or self-custody as well as create this experience that at least on mobile, feels very native, which is a face ID type experience. So yes, short answer is yes. Thank you so much, Itayi. That was fantastic. Please give him a great applause. Thanks, everyone. Appreciate it.",
- "eventId": "devcon-7",
- "slot_start": 1731393600000,
- "slot_end": 1731394200000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1pVk3HgI3jY_eVj3C7F4jVkcdwrwbVFi9NzWDCgBBUFg",
- "resources_slides": null,
"speakers": [
- "itai-turbahn"
- ]
+ "tascha",
+ "loi-luu",
+ "kain-warwick",
+ "namik-muduroglu"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731578400000,
+ "slot_end": 1731582000000,
+ "slot_roomId": "main-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/14OuUArkp-1DdYuHEylurELQO49RZZh5IHebMv6N4LAU"
},
"vector": [
0,
@@ -864090,8 +862236,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -864309,6 +862453,8 @@
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -864816,6 +862962,28 @@
0,
0,
6,
+ 6,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -864852,7 +863020,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -864890,7 +863057,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -864938,7 +863104,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -865008,7 +863173,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -865031,7 +863195,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -865101,7 +863264,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -865202,7 +863364,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -865263,25 +863424,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -865401,6 +863543,7 @@
0,
2,
0,
+ 0,
2,
0,
0,
@@ -865419,41 +863562,43 @@
},
{
"session": {
- "id": "who-wins-ethereum-block-building-auctions-and-why",
- "sourceId": "VKQ8NC",
- "title": "Who Wins Ethereum Block Building Auctions and Why?",
- "description": "Today, top 3 block builders produce over 90% of blocks on Ethereum via MEV-boost auction. The block builder market's dynamics evolve rapidly and has significant impact on the development of private mempools, wallets/apps orderflow auctions, and censorship resistance topic. In this talk, we share an overview of why the top builders win the most market share, using orderflow composition and bidding behavioral data. We hope to highlight the centralizing risks and failures of current market design.",
- "track": "Cryptoeconomics",
+ "id": "why-erc-7683-is-broken-and-how-to-fix-it",
+ "sourceId": "YT3SSN",
+ "title": "Why ERC 7683 is broken and how to fix it",
+ "description": "While I appreciate the authors spending time on this problem statement and thinking about standardising flows, ERC 7683 is deeply flawed it still forces offchain agents to understand the order they are trying to fulfill and it doesnt give users any guarantees of execution or understanding of whats happening under the hood, I think its because its standardising things on the \"intent\" layer where instead we need to standardise more downstream so information like security can be better presented",
+ "track": "Layer 2",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "MEV",
- "PBS",
- "Block Auction"
+ "chain-abstraction",
+ "intents"
],
"tags": [
- "blocks",
- "auction"
+ "Appchains",
+ "Cross-L2",
+ "Token bridging",
+ "Accessibility",
+ "erc-7683",
+ "intent",
+ "Accessibility",
+ "Appchains",
+ "Cross-L2",
+ "Token bridging"
],
"language": "en",
"speakers": [
- "danning-sui",
- "burak-oz"
+ "vaibhav-chellani"
],
"eventId": "devcon-7",
- "slot_start": 1731558600000,
- "slot_end": 1731560400000,
+ "slot_start": 1731479400000,
+ "slot_end": 1731481200000,
"slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1sCbCcL_kcX8oEU3I_BJLpuFgt1wzgpYDENnympxQ7iI"
+ "resources_presentation": "https://docs.google.com/presentation/d/1MNzcD3lH260PkgaznRJQQW41lkxoYMoKXT73MHMNPfg"
},
"vector": [
- 0,
- 0,
- 6,
- 0,
0,
0,
0,
@@ -865461,6 +863606,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -866182,15 +864328,12 @@
0,
0,
0,
- 6,
- 6,
- 0,
- 0,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -866265,6 +864408,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -866349,7 +864493,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -866378,6 +864521,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -866404,8 +864548,10 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
0,
0,
0,
@@ -866749,7 +864895,7 @@
0,
0,
0,
- 0,
+ 2,
0,
0,
0,
@@ -866767,7 +864913,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -866780,43 +864925,49 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "why-defi-matters-on-ethereum",
- "sourceId": "E7GFJC",
- "title": "Why DeFi matters on Ethereum",
- "description": "Why DeFi matters on Ethereum, and why Ethereum is the best place for DeFi.",
- "track": "Real World Ethereum",
- "type": "Panel",
- "expertise": "",
- "audience": "Engineering",
+ "id": "why-ethereums-issuance-policy-is-redacted",
+ "sourceId": "39HYEG",
+ "title": "Why Ethereum's Issuance Policy is [redacted]?",
+ "description": "This talk explores the status quo of staking economics, its drawbacks as we see them and what the future of staking economics could look like.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "none"
+ ],
+ "tags": [
+ "ACD",
+ "Staking",
+ "Economics",
+ "ACD",
+ "Economics",
+ "Staking"
+ ],
"language": "en",
"speakers": [
- "tascha",
- "loi-luu",
- "kain-warwick",
- "namik-muduroglu"
+ "caspar-schwarz-schilling",
+ "ansgar-dietrichs"
],
"eventId": "devcon-7",
- "slot_start": 1731578400000,
- "slot_end": 1731582000000,
- "slot_roomId": "main-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/14OuUArkp-1DdYuHEylurELQO49RZZh5IHebMv6N4LAU"
+ "slot_start": 1731552300000,
+ "slot_end": 1731554100000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1H2muDBPNRQn-IIusKik3f5fD_tsi9lmseX7GwmbUAh8"
},
"vector": [
0,
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -866870,6 +865021,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -867034,8 +865186,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -867545,13 +865695,11 @@
0,
0,
0,
- 6,
- 6,
- 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -867600,6 +865748,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -867693,6 +865842,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -867849,6 +865999,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -868123,9 +866274,9 @@
0,
0,
0,
+ 2,
0,
0,
- 2,
0,
0,
2,
@@ -868140,47 +866291,39 @@
0,
0,
0,
- 0,
0
]
},
{
"session": {
- "id": "why-erc-7683-is-broken-and-how-to-fix-it",
- "sourceId": "YT3SSN",
- "title": "Why ERC 7683 is broken and how to fix it",
- "description": "While I appreciate the authors spending time on this problem statement and thinking about standardising flows, ERC 7683 is deeply flawed it still forces offchain agents to understand the order they are trying to fulfill and it doesnt give users any guarantees of execution or understanding of whats happening under the hood, I think its because its standardising things on the \"intent\" layer where instead we need to standardise more downstream so information like security can be better presented",
- "track": "Layer 2",
+ "id": "why-many-deployed-snarks-are-extremely-risky",
+ "sourceId": "BVSHEA",
+ "title": "Why many deployed SNARKs are extremely risky",
+ "description": "We analyze the real-world security of FRI, a key component in many SNARKs securing billions in blockchain transactions. We discover alarming gaps between conjectured and provable security in deployed FRI parameters. Most cases show 21-63 bits weaker provable security than conjectured. This leaves systems vulnerable if better attacks emerge. We propose guidelines for achieving 100 bits of provable security and a method for parameter tuning, aiming to enhance SNARK security in L2s+blockchains.",
+ "track": "Applied Cryptography",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"keywords": [
- "chain-abstraction",
- "intents"
+ "Concrete",
+ "security"
],
"tags": [
- "Appchains",
- "Cross-L2",
- "Token bridging",
- "Accessibility",
- "erc-7683",
- "intent",
- "Accessibility",
- "Appchains",
- "Cross-L2",
- "Token bridging"
+ "Cryptography",
+ "Security",
+ "SNARK"
],
"language": "en",
"speakers": [
- "vaibhav-chellani"
+ "pratyush-ranjan-tiwari"
],
"eventId": "devcon-7",
- "slot_start": 1731479400000,
- "slot_end": 1731481200000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1MNzcD3lH260PkgaznRJQQW41lkxoYMoKXT73MHMNPfg"
+ "slot_start": 1731645000000,
+ "slot_end": 1731646800000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1p5nM9CjRl-N6-aj7yjsMvrsos4m3GrpVgekyXpMOGfM"
},
"vector": [
0,
@@ -868190,11 +866333,10 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -868933,6 +867075,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -868945,6 +867088,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -868995,7 +867139,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -869108,7 +867251,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -869135,10 +867277,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
0,
0,
0,
@@ -869216,6 +867356,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -869264,7 +867406,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -869482,7 +867623,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -869500,8 +867640,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -869518,45 +867658,54 @@
},
{
"session": {
- "id": "why-ethereums-issuance-policy-is-redacted",
- "sourceId": "39HYEG",
- "title": "Why Ethereum's Issuance Policy is [redacted]?",
- "description": "This talk explores the status quo of staking economics, its drawbacks as we see them and what the future of staking economics could look like.",
- "track": "Core Protocol",
- "type": "Talk",
+ "id": "why-vpns-are-scams-and-what-to-do-about-it",
+ "sourceId": "TRMC3L",
+ "title": "Why VPNs are scams and what to do about it",
+ "description": "Existing VPNs are essentially scams. Free VPNs and most centralized VPNs (such as ExpressVPN, owned by Kape) are effectively data harvesting companies. Decentralized VPNs usually have a few large servers and offer barely any more privacy than centralized VPNs. What is missing is 1) onion-routing packets like Tor 2) adding noise (fake traffic) 3) censorship-resistance and 4) mixing packets from different users together. We'll explore how technologies work to defeat even AI adversaries.",
+ "track": "Cypherpunk & Privacy",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "none"
- ],
"tags": [
- "ACD",
- "Staking",
- "Economics",
- "ACD",
- "Economics",
- "Staking"
+ "censorship",
+ "resistance",
+ "Decentralization",
+ "Privacy",
+ "Use Cases"
],
- "language": "en",
- "speakers": [
- "caspar-schwarz-schilling",
- "ansgar-dietrichs"
+ "keywords": [
+ "VPNs",
+ "mixnets",
+ "censorship-resistance"
],
+ "duration": 538,
+ "language": "en",
+ "sources_swarmHash": "a1d36033bf5ebaf4e1f8ed35812948388d4ba3cb56f13648118d2e9ba837ede6",
+ "sources_youtubeId": "4Ir-fptXPr8",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f66880d989c5b7ab5ce4.vtt",
+ "transcript_text": " . VPNs are scams and what to do about it. Hey, everybody. Okay, cool. Thank you so much for coming. So VPNs, how many people here have a VPN? Okay. Can people just have a VPN? Okay. Can people just name a few they have? What do you use? ExpressVPN? Mulvad? Not so bad. Proton? Free. IVPN? They take Bitcoin, which is cool. I don't know that one. Okay. So I'm just going to explain. I'm Harry Halpin. I did my PhD in language models, which are now very fun and a big deal. But I gave up on working on them because what I realized is that machine learning is very dangerous and can cause problems and basically identify who you are no matter what you're doing on the internet. And one particular source of data for machine learning and identifying people are VPNs. VPNs are scams. All centralized VPNs are scams. Some of them are slightly nicer than others, but it's still basically like protons, like, yo, we're Swiss, trust me, bro. Same with, you know, MoVad, we're Swedish, trust me. And a lot of VPNs, what you think are separate companies, such as NordVPN, Private Internet, Surfshark, they're all ran by like essentially malware delivery companies or data collection companies. They essentially honeypot your data. So they can connect your data. When I use a VPN, I simply connect to someone else's computer. That computer sees all of my traffic. They know exactly what I'm doing on the internet. And they can connect that to my credit card and my address. And they can bundle that data and sell it. Sometimes the government's to ads. It's just they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks we have in the house or ORCID. It's just, they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks do we have in the house? Or Orkid? But the problem is they don't provide actual privacy. An adversary can just look at the DVPNs and de-anonymize you. So what we've decided to do at NIM is we're trying to produce a VPN that's both decentralized and actually delivers privacy even against government level surveillance using AI algorithms. So we do this by adding noise to your connection. So when you connect to a normal VPN they kind of know exactly what you're doing. When you connect to a decentralized VPN a group of nodes knows exactly what you're doing. What we do is we encrypt each packet separately, similar to Tor, but unlike Tor, we mix the packets up, and that's a mixnet for people that are interested in that, and then we add fake traffic or noise. So this is a comparison. This is your normal VPN. You can see this guy can see everything you're doing and this produces a unique fingerprint of your data Nim on the other hand adds fake traffic and the packets come out anonymized and again It's a decentralized network as a decent network. Anyone can run a node you get rewarded and Nim tokens We use zero knowledge proofs to log in So you just send some tokens to a smart contract, you get back a zero knowledge proof, and you log in using a zero knowledge proof. So you don't have your address, but we can prove that you paid open source, so forth and so on. This is maybe a nice little overview of the differences. So again, decentralized routing, no single company in charge that can put in a backdoor, open source, mixing packets, adding cover traffic, and unlinking any payments to your session. And, you know, we have a lot of other cool stuff. We have APIs. You could, in theory, and if you look up my Ethereum ETH DAM or Ethereum Amsterdam talk, we even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus talk. We even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus algorithm. And you can hook up to like client software. Metamask is a bit tricky, but you could use Helios and whatnot and anonymize your transactions that way. So if you're interested, we would like you to give it a shot. It's on Google Play. It's in TestFlight, not quite an app store, DevCon, whatever. Just give us a shot. And I want to say when you install it, you get something that looks like this. You've got to download it, right? So when you go to, you go to nimvpn.com slash download. And then the confusing part is you have to enter your email. Don't worry. You can enter a fake one. We don't care. We don't, it's just like you enter random strings. And then you get a QR code or this. This is a small zero knowledge proof. And then when you start up the VPN, you can choose if you want to be fast, which is no mixing, or you want to be anonymous, which is a mix net, so we mix your packets up, and then you choose where you want to come in. The nearest nodes, I think, here is Singapore, or where you want to come out, and then you cut and paste that QR code in, and then it just works. So that's it. We have a lot of cool stuff coming. Please try it out. It's free for a month so we can defeat fucking authoritarians like Donald Trump and all these motherfuckers. Okay. So, yeah, that's it. Time for Q&A. Okay, Q&A time. So, in this stage we will be throwing this microphone so raise up your hand if you have a question. Oh, and I need opportunity to fuck the deep state Democrats as well. Just so you know. You're first. Okay, catch it. Sorry, I'm not very good at this. I just want to know what's the main complaint of your current users? It's mostly crazy cryptocurrency people doing beta testing. So we have a lot of people in countries which have some form of censorship, folks in Russia, China. We're still working on some of the censorship prevention techniques to get around certain kind of firewalls. But mostly it's just crypto people who are token holders who are just trying it out and having fun. I think we have about 5,000, 6 six thousand people downloading and using it so but it just started basically. But unlike a normal VPN the more people that use it the more anonymous you are unlike Tor or normal VPN so five thousand people is a reasonable size in a mini set. You mentioned earlier Mysterium and Orchid and they both are on the market since the time they both struggle really to get any significant amount of users. What do you think is something we can do about that to get more people to that decentralized world? Yeah, you've got to onboard the normies like normies. So the problem was we looked at Orchid. I like Seven. He's a cool dude. But the problem is that they said, oh pay as you go, so I want to pay for a gigabyte or megabyte. Normal people don't do that. And they also required like some weird token stuff to get the thing going and most people have trouble buying tokens, right? So what we do is we just have a normal fiat interface, Stripe, if you like Bitcoin, my BTC pay, and we take that payment in fiat or whatever and then an API converts that over to NIM token, and then we do an automatic buy of NIM tokens on the open market. So it's all invisible, the token part, and there's tokens that reward the nodes. It's all invisible to the end user. I think the key is to make it look and act as much as possible like a normal VPN, but also offer features that normal VPNs don't have. So we have this anonymous mode, a mixnet, which no one else has. We're the world's first decentralized, actually anonymous mixnet. You know, support Chelsea Manning works for me, Julian Assange is a big fan, and that's something that no normal VPN has. Okay, last question. I'm around afterwards, so you can grab me afterwards. Run, run, run. Throw the ball. Why doesn't Tor just add noise? Tor has looked at it. I actually had dinner with Roger last night. You can ask him this question. They are considering. But Tor is not a mixnet. So Tor optimized for speed, which is reasonable for them to do back when they started their code. And they weren't like, it's complex. You have to have like, figure out like, you guys have to do some form of traffic shaping. And at the time, this was a harder thing to do. Movad's also looking into adding noise. I think they have it working on iOS or one of their clients. It's actually really, it's a large amount of tricky machine learning. So mixnets, particularly what we are called continuous time mixnets, we actually do a default, what's called traffic shaping to Poisson processes. So you don't know when you're packet-arised, but you always know the average time, and that makes adding noise much easier. Okay, I think that's it. I'm sorry.",
"eventId": "devcon-7",
- "slot_start": 1731552300000,
- "slot_end": 1731554100000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1H2muDBPNRQn-IIusKik3f5fD_tsi9lmseX7GwmbUAh8"
+ "slot_start": 1731389400000,
+ "slot_end": 1731390000000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1X40WVD7E27evrL1uMb90tNX_OrjLhOmaw9pd-qrbFB4",
+ "resources_slides": null,
+ "speakers": [
+ "harry-halpin"
+ ]
},
"vector": [
0,
0,
0,
0,
- 6,
0,
+ 6,
0,
0,
0,
@@ -869608,7 +867757,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -870193,6 +868341,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -870289,7 +868438,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -870338,7 +868486,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -870381,6 +868528,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -870403,6 +868551,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -870416,6 +868565,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -870432,7 +868582,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -870590,11 +868739,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -870853,6 +868997,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -870868,7 +869014,6 @@
0,
0,
0,
- 0,
2,
0,
0,
@@ -870881,15 +869026,16 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "why-many-deployed-snarks-are-extremely-risky",
- "sourceId": "BVSHEA",
- "title": "Why many deployed SNARKs are extremely risky",
- "description": "We analyze the real-world security of FRI, a key component in many SNARKs securing billions in blockchain transactions. We discover alarming gaps between conjectured and provable security in deployed FRI parameters. Most cases show 21-63 bits weaker provable security than conjectured. This leaves systems vulnerable if better attacks emerge. We propose guidelines for achieving 100 bits of provable security and a method for parameter tuning, aiming to enhance SNARK security in L2s+blockchains.",
+ "id": "wizard-build-your-own-p-iop-protocol-in-15-min",
+ "sourceId": "W78CYD",
+ "title": "Wizard: build your own P-IOP protocol in 15 min!",
+ "description": "Wizard is a new open-source framework allowing you to write your own ZK proving scheme. Wizard is one of the backbones of Linea zkEVM's prover and it can be used to implement advanced protocols easily. In this session I will guide you through an implementation of Plonk using just a few lines of code.",
"track": "Applied Cryptography",
"type": "Talk",
"expertise": "Intermediate",
@@ -870897,23 +869043,26 @@
"featured": false,
"doNotRecord": false,
"keywords": [
- "Concrete",
- "security"
+ "Polynomial-IOP"
],
"tags": [
- "Cryptography",
- "Security",
+ "Protocol Design",
+ "Frameworks",
+ "SNARK",
+ "polynomial-iop",
+ "Frameworks",
+ "Protocol Design",
"SNARK"
],
"language": "en",
"speakers": [
- "pratyush-ranjan-tiwari"
+ "alexandre-belling"
],
"eventId": "devcon-7",
- "slot_start": 1731645000000,
- "slot_end": 1731646800000,
+ "slot_start": 1731486600000,
+ "slot_end": 1731488400000,
"slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1p5nM9CjRl-N6-aj7yjsMvrsos4m3GrpVgekyXpMOGfM"
+ "resources_presentation": "https://docs.google.com/presentation/d/1FkV9X3aQwU20vdTZXHXBpHGRAISg06VrxYifChRhnIo"
},
"vector": [
0,
@@ -871653,8 +869802,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -871668,8 +869815,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -871681,8 +869826,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -871717,6 +869860,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -871775,6 +869919,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -872219,6 +870364,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -872251,48 +870397,31 @@
},
{
"session": {
- "id": "why-vpns-are-scams-and-what-to-do-about-it",
- "sourceId": "TRMC3L",
- "title": "Why VPNs are scams and what to do about it",
- "description": "Existing VPNs are essentially scams. Free VPNs and most centralized VPNs (such as ExpressVPN, owned by Kape) are effectively data harvesting companies. Decentralized VPNs usually have a few large servers and offer barely any more privacy than centralized VPNs. What is missing is 1) onion-routing packets like Tor 2) adding noise (fake traffic) 3) censorship-resistance and 4) mixing packets from different users together. We'll explore how technologies work to defeat even AI adversaries.",
- "track": "Cypherpunk & Privacy",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
+ "id": "wmb-81321",
+ "sourceId": "S8MPDK",
+ "title": "WMB 81321",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "tags": [
- "censorship",
- "resistance",
- "Decentralization",
- "Privacy",
- "Use Cases"
- ],
- "keywords": [
- "VPNs",
- "mixnets",
- "censorship-resistance"
- ],
- "duration": 538,
+ "keywords": [],
+ "tags": [],
"language": "en",
- "sources_swarmHash": "a1d36033bf5ebaf4e1f8ed35812948388d4ba3cb56f13648118d2e9ba837ede6",
- "sources_youtubeId": "4Ir-fptXPr8",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6732f66880d989c5b7ab5ce4.vtt",
- "transcript_text": " . VPNs are scams and what to do about it. Hey, everybody. Okay, cool. Thank you so much for coming. So VPNs, how many people here have a VPN? Okay. Can people just have a VPN? Okay. Can people just name a few they have? What do you use? ExpressVPN? Mulvad? Not so bad. Proton? Free. IVPN? They take Bitcoin, which is cool. I don't know that one. Okay. So I'm just going to explain. I'm Harry Halpin. I did my PhD in language models, which are now very fun and a big deal. But I gave up on working on them because what I realized is that machine learning is very dangerous and can cause problems and basically identify who you are no matter what you're doing on the internet. And one particular source of data for machine learning and identifying people are VPNs. VPNs are scams. All centralized VPNs are scams. Some of them are slightly nicer than others, but it's still basically like protons, like, yo, we're Swiss, trust me, bro. Same with, you know, MoVad, we're Swedish, trust me. And a lot of VPNs, what you think are separate companies, such as NordVPN, Private Internet, Surfshark, they're all ran by like essentially malware delivery companies or data collection companies. They essentially honeypot your data. So they can connect your data. When I use a VPN, I simply connect to someone else's computer. That computer sees all of my traffic. They know exactly what I'm doing on the internet. And they can connect that to my credit card and my address. And they can bundle that data and sell it. Sometimes the government's to ads. It's just they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks we have in the house or ORCID. It's just, they're absolutely terrible. Decentralized VPNs have been going on for a while. How many Mysterium folks do we have in the house? Or Orkid? But the problem is they don't provide actual privacy. An adversary can just look at the DVPNs and de-anonymize you. So what we've decided to do at NIM is we're trying to produce a VPN that's both decentralized and actually delivers privacy even against government level surveillance using AI algorithms. So we do this by adding noise to your connection. So when you connect to a normal VPN they kind of know exactly what you're doing. When you connect to a decentralized VPN a group of nodes knows exactly what you're doing. What we do is we encrypt each packet separately, similar to Tor, but unlike Tor, we mix the packets up, and that's a mixnet for people that are interested in that, and then we add fake traffic or noise. So this is a comparison. This is your normal VPN. You can see this guy can see everything you're doing and this produces a unique fingerprint of your data Nim on the other hand adds fake traffic and the packets come out anonymized and again It's a decentralized network as a decent network. Anyone can run a node you get rewarded and Nim tokens We use zero knowledge proofs to log in So you just send some tokens to a smart contract, you get back a zero knowledge proof, and you log in using a zero knowledge proof. So you don't have your address, but we can prove that you paid open source, so forth and so on. This is maybe a nice little overview of the differences. So again, decentralized routing, no single company in charge that can put in a backdoor, open source, mixing packets, adding cover traffic, and unlinking any payments to your session. And, you know, we have a lot of other cool stuff. We have APIs. You could, in theory, and if you look up my Ethereum ETH DAM or Ethereum Amsterdam talk, we even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus talk. We even showed how to integrate against Ethereum validators to prevent various DDoS attacks on the Ethereum consensus algorithm. And you can hook up to like client software. Metamask is a bit tricky, but you could use Helios and whatnot and anonymize your transactions that way. So if you're interested, we would like you to give it a shot. It's on Google Play. It's in TestFlight, not quite an app store, DevCon, whatever. Just give us a shot. And I want to say when you install it, you get something that looks like this. You've got to download it, right? So when you go to, you go to nimvpn.com slash download. And then the confusing part is you have to enter your email. Don't worry. You can enter a fake one. We don't care. We don't, it's just like you enter random strings. And then you get a QR code or this. This is a small zero knowledge proof. And then when you start up the VPN, you can choose if you want to be fast, which is no mixing, or you want to be anonymous, which is a mix net, so we mix your packets up, and then you choose where you want to come in. The nearest nodes, I think, here is Singapore, or where you want to come out, and then you cut and paste that QR code in, and then it just works. So that's it. We have a lot of cool stuff coming. Please try it out. It's free for a month so we can defeat fucking authoritarians like Donald Trump and all these motherfuckers. Okay. So, yeah, that's it. Time for Q&A. Okay, Q&A time. So, in this stage we will be throwing this microphone so raise up your hand if you have a question. Oh, and I need opportunity to fuck the deep state Democrats as well. Just so you know. You're first. Okay, catch it. Sorry, I'm not very good at this. I just want to know what's the main complaint of your current users? It's mostly crazy cryptocurrency people doing beta testing. So we have a lot of people in countries which have some form of censorship, folks in Russia, China. We're still working on some of the censorship prevention techniques to get around certain kind of firewalls. But mostly it's just crypto people who are token holders who are just trying it out and having fun. I think we have about 5,000, 6 six thousand people downloading and using it so but it just started basically. But unlike a normal VPN the more people that use it the more anonymous you are unlike Tor or normal VPN so five thousand people is a reasonable size in a mini set. You mentioned earlier Mysterium and Orchid and they both are on the market since the time they both struggle really to get any significant amount of users. What do you think is something we can do about that to get more people to that decentralized world? Yeah, you've got to onboard the normies like normies. So the problem was we looked at Orchid. I like Seven. He's a cool dude. But the problem is that they said, oh pay as you go, so I want to pay for a gigabyte or megabyte. Normal people don't do that. And they also required like some weird token stuff to get the thing going and most people have trouble buying tokens, right? So what we do is we just have a normal fiat interface, Stripe, if you like Bitcoin, my BTC pay, and we take that payment in fiat or whatever and then an API converts that over to NIM token, and then we do an automatic buy of NIM tokens on the open market. So it's all invisible, the token part, and there's tokens that reward the nodes. It's all invisible to the end user. I think the key is to make it look and act as much as possible like a normal VPN, but also offer features that normal VPNs don't have. So we have this anonymous mode, a mixnet, which no one else has. We're the world's first decentralized, actually anonymous mixnet. You know, support Chelsea Manning works for me, Julian Assange is a big fan, and that's something that no normal VPN has. Okay, last question. I'm around afterwards, so you can grab me afterwards. Run, run, run. Throw the ball. Why doesn't Tor just add noise? Tor has looked at it. I actually had dinner with Roger last night. You can ask him this question. They are considering. But Tor is not a mixnet. So Tor optimized for speed, which is reasonable for them to do back when they started their code. And they weren't like, it's complex. You have to have like, figure out like, you guys have to do some form of traffic shaping. And at the time, this was a harder thing to do. Movad's also looking into adding noise. I think they have it working on iOS or one of their clients. It's actually really, it's a large amount of tricky machine learning. So mixnets, particularly what we are called continuous time mixnets, we actually do a default, what's called traffic shaping to Poisson processes. So you don't know when you're packet-arised, but you always know the average time, and that makes adding noise much easier. Okay, I think that's it. I'm sorry.",
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731389400000,
- "slot_end": 1731390000000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1X40WVD7E27evrL1uMb90tNX_OrjLhOmaw9pd-qrbFB4",
- "resources_slides": null,
- "speakers": [
- "harry-halpin"
- ]
+ "slot_start": 1731661200000,
+ "slot_end": 1731664800000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1IuOY3B48xD6oQfkmw66ZED8btQYpPlx-woDEIDkmuwQ"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -872938,7 +871067,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -873124,7 +871252,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -873147,7 +871274,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -873161,7 +871287,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -873593,8 +871718,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -873609,7 +871732,6 @@
2,
0,
0,
- 0,
2,
0,
0,
@@ -873628,37 +871750,35 @@
},
{
"session": {
- "id": "wizard-build-your-own-p-iop-protocol-in-15-min",
- "sourceId": "W78CYD",
- "title": "Wizard: build your own P-IOP protocol in 15 min!",
- "description": "Wizard is a new open-source framework allowing you to write your own ZK proving scheme. Wizard is one of the backbones of Linea zkEVM's prover and it can be used to implement advanced protocols easily. In this session I will guide you through an implementation of Plonk using just a few lines of code.",
- "track": "Applied Cryptography",
+ "id": "working-together-with-unity-blazor-nethereum-and-mud",
+ "sourceId": "SDUYDQ",
+ "title": "Working together with Unity, Blazor, Nethereum and MUD",
+ "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and explores how Unity, Blazor, Nethereum, and MUD integrate to build blockchain-based games and applications. It covers the overall architecture and structure of .NET projects, including smart contract integration and core logic. Key topics include Nethereum's integration with MUD systems and tables, extended code generation to support MUD, deployment strategies, bulk saving, data synchronization, and testing.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Research",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Polynomial-IOP"
+ "Nethereum",
+ "MUD",
+ "Unity"
],
"tags": [
- "Protocol Design",
- "Frameworks",
- "SNARK",
- "polynomial-iop",
+ "Architecture",
"Frameworks",
- "Protocol Design",
- "SNARK"
+ "Gaming"
],
"language": "en",
"speakers": [
- "alexandre-belling"
+ "juan-blanco"
],
"eventId": "devcon-7",
- "slot_start": 1731486600000,
- "slot_end": 1731488400000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1FkV9X3aQwU20vdTZXHXBpHGRAISg06VrxYifChRhnIo"
+ "slot_start": 1731568500000,
+ "slot_end": 1731570000000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1cgSTfVg9G2fBhaLSYwdokUa1BNjwvijZP4qAjaifH3Q"
},
"vector": [
0,
@@ -873671,11 +871791,9 @@
0,
0,
0,
- 6,
- 0,
- 0,
0,
0,
+ 6,
0,
0,
0,
@@ -874459,8 +872577,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -874476,6 +872592,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -874524,6 +872641,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -874695,7 +872813,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -874963,7 +873080,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -874974,8 +873090,8 @@
0,
0,
0,
- 2,
0,
+ 2,
0,
0,
0,
@@ -874991,30 +873107,47 @@
0,
0,
0,
+ 0,
0
]
},
{
"session": {
- "id": "wmb-81321",
- "sourceId": "S8MPDK",
- "title": "WMB 81321",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
- "audience": "Engineering",
+ "id": "wtf-are-based-rollups-and-preconfs",
+ "sourceId": "UG79AE",
+ "title": "Wtf are based rollups and preconfs?",
+ "description": "The rollup-centric roadmap is critical for scaling Ethereum but has introduced fragmentation of users, developers, and liquidity. But don't worry, based rollups are here to save the day! But wtf is a “based rollup”? And wtf are these “pre-confs” that usually get talked about together?\r\n\r\nThe focus of this talk is to demystify these concepts and try and get more people engaged in the based rollup ecosystem, which has the potential to heal Ethereum’s fragmentation problem.",
+ "track": "Layer 2",
+ "type": "Lightning Talk",
+ "expertise": "Beginner",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "keywords": [
+ "Based Rollup",
+ "Preconfirmations",
+ "Sequencing"
+ ],
+ "tags": [
+ "Validator Experience",
+ "Layer 2s",
+ "Rollups",
+ "sequencer",
+ "preconfs",
+ "pre-confirmations",
+ "Layer 2s",
+ "Rollups",
+ "Validator Experience"
+ ],
"language": "en",
- "speakers": [],
+ "speakers": [
+ "jason-vranek"
+ ],
"eventId": "devcon-7",
- "slot_start": 1731661200000,
- "slot_end": 1731664800000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1IuOY3B48xD6oQfkmw66ZED8btQYpPlx-woDEIDkmuwQ"
+ "slot_start": 1731642000000,
+ "slot_end": 1731642600000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1XBmbnq_59WsG85OTcNpUu6A8prP6pC2w2YjOs_3x7-Y"
},
"vector": [
0,
@@ -875024,8 +873157,6 @@
0,
0,
0,
- 0,
- 0,
6,
0,
0,
@@ -875758,6 +873889,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -875805,8 +873937,11 @@
0,
0,
0,
+ 2,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -875830,6 +873965,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -875875,13 +874011,8 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
+ 2,
+ 2,
0,
0,
0,
@@ -876334,9 +874465,8 @@
2,
0,
0,
- 2,
- 0,
0,
+ 2,
0,
0,
0,
@@ -876352,35 +874482,37 @@
},
{
"session": {
- "id": "working-together-with-unity-blazor-nethereum-and-mud",
- "sourceId": "SDUYDQ",
- "title": "Working together with Unity, Blazor, Nethereum and MUD",
- "description": "This is a project demo as part of the MUD Day CLS: autonomous worlds, onchain games, and explores how Unity, Blazor, Nethereum, and MUD integrate to build blockchain-based games and applications. It covers the overall architecture and structure of .NET projects, including smart contract integration and core logic. Key topics include Nethereum's integration with MUD systems and tables, extended code generation to support MUD, deployment strategies, bulk saving, data synchronization, and testing.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Talk",
+ "id": "wtf-is-the-pessimistic-proof",
+ "sourceId": "DAZLVG",
+ "title": "WTF is the pessimistic proof",
+ "description": "Cryptographic safety for the AggLayer requires a novel solution. It’s called the pessimistic proof and it treats all chains suspiciously. The AggLayer will be a decentralized protocol that scales blockchains by unifying liquidity, users, and state. The Pessimistic proof is a proof generated to securely grant this shared liquidity, and it will be technically explained in this flash talk by one of the developers.",
+ "track": "Layer 2",
+ "type": "Lightning Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Nethereum",
- "MUD",
- "Unity"
+ "aggLayer",
+ "shared liquidity"
],
"tags": [
- "Architecture",
- "Frameworks",
- "Gaming"
+ "ZKP",
+ "liquidity",
+ "shared",
+ "agglayer",
+ "ZKP"
],
"language": "en",
"speakers": [
- "juan-blanco"
+ "ignasi-ramos",
+ "jesus"
],
"eventId": "devcon-7",
- "slot_start": 1731568500000,
- "slot_end": 1731570000000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1cgSTfVg9G2fBhaLSYwdokUa1BNjwvijZP4qAjaifH3Q"
+ "slot_start": 1731654000000,
+ "slot_end": 1731654600000,
+ "slot_roomId": "stage-4",
+ "resources_presentation": "https://docs.google.com/presentation/d/1BLkd5LgVpoznDQEyKsIo9P94GZyyUdEhmVBoZTS692Q"
},
"vector": [
0,
@@ -876390,12 +874522,12 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -876885,6 +875017,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -877056,6 +875189,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -877124,7 +875258,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -877197,11 +875330,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -877211,6 +875339,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -877219,6 +875348,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -877240,14 +875370,11 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -877688,6 +875815,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -877718,41 +875847,34 @@
},
{
"session": {
- "id": "wtf-are-based-rollups-and-preconfs",
- "sourceId": "UG79AE",
- "title": "Wtf are based rollups and preconfs?",
- "description": "The rollup-centric roadmap is critical for scaling Ethereum but has introduced fragmentation of users, developers, and liquidity. But don't worry, based rollups are here to save the day! But wtf is a “based rollup”? And wtf are these “pre-confs” that usually get talked about together?\r\n\r\nThe focus of this talk is to demystify these concepts and try and get more people engaged in the based rollup ecosystem, which has the potential to heal Ethereum’s fragmentation problem.",
- "track": "Layer 2",
- "type": "Lightning Talk",
+ "id": "yeomenai-elevate-your-game",
+ "sourceId": "WLKTYW",
+ "title": "Yeomen.ai - Elevate your game!",
+ "description": "Talk as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nWeb3 games bring about possibilities for autonomous worlds that traditional games are not able to offer. Yeomen.ai makes the on-chain data available to the masses in simple dashboards. Yeomen.ai also offers on-chain extension of autonomous worlds to automate and transform game play.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
+ "type": "Talk",
"expertise": "Beginner",
"audience": "Developer",
"featured": false,
"doNotRecord": false,
"keywords": [
- "Based Rollup",
- "Preconfirmations",
- "Sequencing"
+ "Analytics",
+ "Modding"
],
"tags": [
- "Validator Experience",
- "Layer 2s",
- "Rollups",
- "sequencer",
- "preconfs",
- "pre-confirmations",
- "Layer 2s",
- "Rollups",
- "Validator Experience"
+ "Autonomous World",
+ "Developer Infrastructure"
],
"language": "en",
"speakers": [
- "jason-vranek"
+ "rohan-abraham",
+ "roshan-abraham"
],
"eventId": "devcon-7",
- "slot_start": 1731642000000,
- "slot_end": 1731642600000,
+ "slot_start": 1731580800000,
+ "slot_end": 1731582300000,
"slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1XBmbnq_59WsG85OTcNpUu6A8prP6pC2w2YjOs_3x7-Y"
+ "resources_presentation": "https://docs.google.com/presentation/d/1-3KWguxf1wrbuaxgSi8ewkempDUuj4_SzXw0fz2dbbU"
},
"vector": [
0,
@@ -877762,12 +875884,12 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -878495,9 +876617,10 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
- 6,
0,
0,
0,
@@ -878545,11 +876668,8 @@
0,
0,
0,
- 2,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -878560,6 +876680,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -878573,7 +876694,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -878616,11 +876736,10 @@
0,
0,
0,
+ 2,
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -879090,37 +877209,35 @@
},
{
"session": {
- "id": "wtf-is-the-pessimistic-proof",
- "sourceId": "DAZLVG",
- "title": "WTF is the pessimistic proof",
- "description": "Cryptographic safety for the AggLayer requires a novel solution. It’s called the pessimistic proof and it treats all chains suspiciously. The AggLayer will be a decentralized protocol that scales blockchains by unifying liquidity, users, and state. The Pessimistic proof is a proof generated to securely grant this shared liquidity, and it will be technically explained in this flash talk by one of the developers.",
- "track": "Layer 2",
+ "id": "yeomenai-mud-day-demo",
+ "sourceId": "7DGLCG",
+ "title": "Yeomen.ai - MUD Day Demo",
+ "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nYeomen.ai is building dashboards, automation tools, marketplaces, and platforms for autonomous worlds and onchain games built with MUD. Rohan will showcase some of these tools in this demo session.",
+ "track": "[CLS] MUD Community-Led Session, by 0xPARC",
"type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
+ "expertise": "Beginner",
+ "audience": "Product",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "aggLayer",
- "shared liquidity"
- ],
+ "keywords": [],
"tags": [
- "ZKP",
- "liquidity",
- "shared",
- "agglayer",
- "ZKP"
+ "Tooling",
+ "Gaming",
+ "Autonomous World",
+ "analytics",
+ "Autonomous World",
+ "Gaming",
+ "Tooling"
],
"language": "en",
"speakers": [
- "ignasi-ramos",
- "jesus"
+ "rohan-abraham"
],
"eventId": "devcon-7",
- "slot_start": 1731654000000,
- "slot_end": 1731654600000,
- "slot_roomId": "stage-4",
- "resources_presentation": "https://docs.google.com/presentation/d/1BLkd5LgVpoznDQEyKsIo9P94GZyyUdEhmVBoZTS692Q"
+ "slot_start": 1731558600000,
+ "slot_end": 1731558900000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1D2DHsWzGk1OOmOYP0VkdpHHHgEYGIOx9nMKOiTdQw-Y"
},
"vector": [
0,
@@ -879130,12 +877247,12 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -879630,7 +877747,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -879801,7 +877917,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -879865,6 +877980,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -879894,6 +878010,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -879945,12 +878062,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
0,
0,
0,
@@ -879959,7 +878076,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -879983,6 +878099,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -880426,8 +878544,6 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
@@ -880440,11 +878556,9 @@
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
+ 2,
0,
0,
0,
@@ -880458,34 +878572,42 @@
},
{
"session": {
- "id": "yeomenai-elevate-your-game",
- "sourceId": "WLKTYW",
- "title": "Yeomen.ai - Elevate your game!",
- "description": "Talk as part of the MUD Day CLS: autonomous worlds, onchain games, and non-financial applications.\r\n\r\nWeb3 games bring about possibilities for autonomous worlds that traditional games are not able to offer. Yeomen.ai makes the on-chain data available to the masses in simple dashboards. Yeomen.ai also offers on-chain extension of autonomous worlds to automate and transform game play.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Talk",
- "expertise": "Beginner",
- "audience": "Developer",
+ "id": "you-know-whats-going-to-get-us-from-web2-to-web3-therapy",
+ "sourceId": "LUKWAM",
+ "title": "You know what’s going to get us from web2 to web3? Therapy",
+ "description": "2024 has been about thinking how we avoid recreating the same systems just \"over here\". And it has to start with our intentions and our ability to make decisions from a better place vs continuing to be influenced by scarcity mindsets, disregulated nervous systems and a burntout collective. \r\n\r\nI delve deeper into this here https://pop.mirror.xyz/JoTHH4cSRw967mphJqur6hWS6vQx0q89ee0WnO1o63g",
+ "track": "Coordination",
+ "type": "Lightning Talk",
+ "expertise": "Intermediate",
+ "audience": "Community",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Analytics",
- "Modding"
- ],
"tags": [
- "Autonomous World",
- "Developer Infrastructure"
+ "future"
],
- "language": "en",
- "speakers": [
- "rohan-abraham",
- "roshan-abraham"
+ "keywords": [
+ "thriving",
+ "mental health",
+ "future"
],
+ "duration": 531,
+ "language": "en",
+ "sources_swarmHash": "b56e50859f10264bce39a4458b8d038188b99b991e4359c0f173ef425205fdfe",
+ "sources_youtubeId": "mKDf6mBemhg",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67346f749dbb7a90e1e77b65.vtt",
+ "transcript_text": " I have a very special speaker, Simona Pop. She's going to give us a talk on, you know what's going to get us from Web 2 to Web 3? Therapy. Let's welcome Simona. Hi. Hello. Hi. Okay, so this is a super sped up version of the talk that I gave at ECC this year with slight improvements, obviously, because I wasn't going to talk to you about the same thing. These are my socials so we can continue this conversation because this is going to be a marathon. I talk a lot. So we're going to go a little bit over. Sorry. Okay, so what's going to get us from Web 2 to Web 3? It's clearly therapy. Here's the agenda. These are all slides that you can take photos of and then read later because I'm going to go real fast. So I tweeted this pretty much a year and a bit ago because I very, very deeply felt it at the time. This is after I burnt myself out and had to, like the end of 2022 at DEF CON in Bogota, somebody asked me, Simona, what are you excited about next year? And I said, nothing. And so I was like, oh, damn, that's not good. And so I realized, and i used to like fool myself and say oh yeah i was on the brink of burnout no it's probably burnout for like a year and a half um i have been in this ecosystem for seven years it is very intense as we know and we kind of need to be mindful of how we're treating the humans behind the protocols and the humans behind the tech, I say this with personal interest in mind because therapy has benefited me greatly. We're in a space of all of the innovation. And the thing is, we have all of these ingredients that are prime for innovation. We're free to think, experiment and speculate. However, the technology isn't the only thing that's going to help us innovate. We need a shift in the values and the thinking and the way we approach things. And I genuinely believe that we need that in order to build better things or build things differently. Why? Because, as Maslow, we know him, he loves pyramids, he said, you can continuously go towards growth or fall back into safety. What keeps us into safety? Even when it is very, very bad for us, our nervous system is designed to keep us safe, even if it is, again, bad. Think of it from, bless you, think of it from the perspective of WIP2 going into WIP3. Some people and a lot of people actually would rather remain where they are because they're afraid to grow. Let us not be in that space and have and facilitate within ourselves and within our collective the opportunity and the way for us to continue towards growth again not just technological but also in terms of human thriving. Because I firmly believe that the societies and economies we build are a reflection of our conscious and unconscious conditioning. We have been conditioned and bastardized into intense scarcity mindsets, intense, just, combative and extractive ways of behaving and being that I genuinely think if we are going to build something different with this technology because of this technology we need to shift out of that and we need to be aware enough to know what we are doing in order to do that until you make the unconscious conscious it will direct your life and you will call it fate. We have the opportunity because of this incredible technology that we're all working on. If we're aware enough, we can actually not just repeat the stuff that we have built just over here. We have the ability and the opportunity to genuinely change things and redesign things at many, many different levels that get to benefit us personally, that get to benefit us as a collective, that get to benefit us hopefully for generations to come. A lot of responsibility. But what it also does, when you're self-aware and when, and we're leading into this. Oh, my God, I'm going so slow. Okay. You can access like higher core needs, right? Those take a photo of that because those are important. When you're stressed, you do not think about those things. You think about how can I get mine? How can I satisfy my base, base needs? And you make bad decisions when you're stressed. You make decisions out of survival. Now, if we think people are in charge of billions of dollars and building technology that can genuinely change lives, we don't want them making bad decisions because they're stressed. We don't want them making bad decisions because they're not aware that they have some sort of child-based wound that makes them want to extract money versus build something that is better. So this is important. So like, yeah, read it later. This was a poll that I did for ACC where it gives you some stats about where our community is. If you see most people are feeling not great, anxious, meh, tired. Some people are feeling good, which is good. But also these are some of the challenges that are incredible stressors for our nervous systems. And these are very, very real elements of our ecosystem. Like that can put you into intense stress. And we need to be mindful of that. And we need to make sure that the people building in this ecosystem have ways of dealing with these things or we as an ecosystem are dealing with those things and are aware of those things. Burnout, that was also me. So 70% said they burnt out at least once. So that's not good. Anxiety is on the daily most of the time, so again, a very, very important factor, especially when we want this to be something that the talented humans are building in this ecosystem, kind of do it more than a year or two. You get the gist. Okay, sorry, do you want to take a photo? I mean, do it quick. But you get it. So again, this was something that I did at ECC, and this would be the practical thing that I'm suggesting. So a human protocol that's like, puts the focus on the humans behind the tech. Because I think there should be a base protocol, a base layer protocol that focuses on the humans. If we want all of us here to continue being creative, to continue having energy to do this, to continue making decisions from a higher value place, we need to have regulated nervous systems. And we need to be aware of what it is that we're doing, why we're driving certain things, why we're making certain decisions, how we're making those decisions. And I think this needs to be implemented the same way as we talk about tech protocols. A human protocol is as important as far as I'm concerned. These are the benefits and the purpose and the vision, obviously. And here, just because when you talk about therapy or talk about anything like this, it's very scary. I'm not saying that people are crazy, although a lot of us are. But these are kind of the stages. You don't have to go full ham on like get everybody on the team therapy. You can start very small, like a pilot, and then implement it, and then grow from there in stages, which I think is, again, a very, very important thing to do something gradual because, again, not everybody is comfortable with a lot of things when it comes to therapy, when it comes to stress management, when it comes to, again, regulating a nervous system. Most people don't know how to do that, and it's an important, very important tool to have. And then, yeah, this is a great meme. I made it. And then, yeah, thank you. How much older was I?",
"eventId": "devcon-7",
- "slot_start": 1731582300000,
- "slot_end": 1731583800000,
+ "slot_start": 1731487800000,
+ "slot_end": 1731488400000,
"slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1-3KWguxf1wrbuaxgSi8ewkempDUuj4_SzXw0fz2dbbU"
+ "resources_presentation": "https://docs.google.com/presentation/d/1gUdSnWcxJdTYFT1JrkVP_VWgSxrlBCcEuwRk8pzgBSA",
+ "resources_slides": null,
+ "speakers": [
+ "simona-pop"
+ ]
},
"vector": [
0,
@@ -880499,7 +878621,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -880693,6 +878814,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -881231,8 +879353,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -881294,8 +879414,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -881350,7 +879468,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -881807,12 +879924,14 @@
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
+ 2,
+ 0,
+ 0,
0,
0,
0,
@@ -881823,37 +879942,74 @@
},
{
"session": {
- "id": "yeomenai-mud-day-demo",
- "sourceId": "7DGLCG",
- "title": "Yeomen.ai - MUD Day Demo",
- "description": "This is a project demo for MUD Day CLS: onchain games and non-financial applications. \r\n\r\nYeomen.ai is building dashboards, automation tools, marketplaces, and platforms for autonomous worlds and onchain games built with MUD. Rohan will showcase some of these tools in this demo session.",
- "track": "[CLS] MUD Community-Led Session, by 0xPARC",
- "type": "Lightning Talk",
- "expertise": "Beginner",
- "audience": "Product",
+ "id": "your-intuition-antoine-flute-and-didgeridoo",
+ "sourceId": "B8SMVZ",
+ "title": "Your intuition Antoine flute and didgeridoo",
+ "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
+ "track": "Entertainment",
+ "type": "Music",
+ "expertise": "",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
"keywords": [],
- "tags": [
- "Tooling",
- "Gaming",
- "Autonomous World",
- "analytics",
- "Autonomous World",
- "Gaming",
- "Tooling"
- ],
+ "tags": [],
"language": "en",
- "speakers": [
- "rohan-abraham"
- ],
+ "speakers": [],
"eventId": "devcon-7",
- "slot_start": 1731558600000,
- "slot_end": 1731558900000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1D2DHsWzGk1OOmOYP0VkdpHHHgEYGIOx9nMKOiTdQw-Y"
+ "slot_start": 1731389400000,
+ "slot_end": 1731391200000,
+ "slot_roomId": "music-stage",
+ "resources_presentation": "https://docs.google.com/presentation/d/1y6uMrtpD3uRb_lrG6TXEsSK_UJ8-x7X4UM7zvdFJaIY"
},
"vector": [
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 6,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -881866,7 +880022,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -882597,7 +880752,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -882627,7 +880781,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -882679,52 +880832,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -883167,6 +881274,7 @@
0,
0,
0,
+ 2,
0,
0,
2,
@@ -883175,8 +881283,6 @@
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -883189,52 +881295,45 @@
},
{
"session": {
- "id": "you-know-whats-going-to-get-us-from-web2-to-web3-therapy",
- "sourceId": "LUKWAM",
- "title": "You know what’s going to get us from web2 to web3? Therapy",
- "description": "2024 has been about thinking how we avoid recreating the same systems just \"over here\". And it has to start with our intentions and our ability to make decisions from a better place vs continuing to be influenced by scarcity mindsets, disregulated nervous systems and a burntout collective. \r\n\r\nI delve deeper into this here https://pop.mirror.xyz/JoTHH4cSRw967mphJqur6hWS6vQx0q89ee0WnO1o63g",
- "track": "Coordination",
- "type": "Lightning Talk",
- "expertise": "Intermediate",
- "audience": "Community",
+ "id": "zero-to-dapp",
+ "sourceId": "LUW7G9",
+ "title": "Zero To Dapp",
+ "description": "Learning Web3 programming. There are so many different tools and protocols to learn. Zero to Dapp is a workshop series that builds upon collaboration between different projects to guide the students from zero to their first Dapp. In this workshop, we review our learning from previous editions to encourage others give their own Zero to Dapp. Then we'll give a shortened version - usually, this workshop takes between a half day up to two full days. But we are fast learners at DevCon, aren’t we? ;)",
+ "track": "Developer Experience",
+ "type": "Workshop",
+ "expertise": "Beginner",
+ "audience": "Developer",
"featured": false,
"doNotRecord": false,
- "tags": [
- "future"
- ],
"keywords": [
- "thriving",
- "mental health",
- "future"
+ "Onboarding"
+ ],
+ "tags": [
+ "Layer 1",
+ "Layer 2s",
+ "Tooling",
+ "DevRel",
+ "Live Coding",
+ "onboarding",
+ "DevRel",
+ "Layer 1",
+ "Layer 2s",
+ "Live Coding",
+ "Tooling"
],
- "duration": 531,
"language": "en",
- "sources_swarmHash": "b56e50859f10264bce39a4458b8d038188b99b991e4359c0f173ef425205fdfe",
- "sources_youtubeId": "mKDf6mBemhg",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/67346f749dbb7a90e1e77b65.vtt",
- "transcript_text": " I have a very special speaker, Simona Pop. She's going to give us a talk on, you know what's going to get us from Web 2 to Web 3? Therapy. Let's welcome Simona. Hi. Hello. Hi. Okay, so this is a super sped up version of the talk that I gave at ECC this year with slight improvements, obviously, because I wasn't going to talk to you about the same thing. These are my socials so we can continue this conversation because this is going to be a marathon. I talk a lot. So we're going to go a little bit over. Sorry. Okay, so what's going to get us from Web 2 to Web 3? It's clearly therapy. Here's the agenda. These are all slides that you can take photos of and then read later because I'm going to go real fast. So I tweeted this pretty much a year and a bit ago because I very, very deeply felt it at the time. This is after I burnt myself out and had to, like the end of 2022 at DEF CON in Bogota, somebody asked me, Simona, what are you excited about next year? And I said, nothing. And so I was like, oh, damn, that's not good. And so I realized, and i used to like fool myself and say oh yeah i was on the brink of burnout no it's probably burnout for like a year and a half um i have been in this ecosystem for seven years it is very intense as we know and we kind of need to be mindful of how we're treating the humans behind the protocols and the humans behind the tech, I say this with personal interest in mind because therapy has benefited me greatly. We're in a space of all of the innovation. And the thing is, we have all of these ingredients that are prime for innovation. We're free to think, experiment and speculate. However, the technology isn't the only thing that's going to help us innovate. We need a shift in the values and the thinking and the way we approach things. And I genuinely believe that we need that in order to build better things or build things differently. Why? Because, as Maslow, we know him, he loves pyramids, he said, you can continuously go towards growth or fall back into safety. What keeps us into safety? Even when it is very, very bad for us, our nervous system is designed to keep us safe, even if it is, again, bad. Think of it from, bless you, think of it from the perspective of WIP2 going into WIP3. Some people and a lot of people actually would rather remain where they are because they're afraid to grow. Let us not be in that space and have and facilitate within ourselves and within our collective the opportunity and the way for us to continue towards growth again not just technological but also in terms of human thriving. Because I firmly believe that the societies and economies we build are a reflection of our conscious and unconscious conditioning. We have been conditioned and bastardized into intense scarcity mindsets, intense, just, combative and extractive ways of behaving and being that I genuinely think if we are going to build something different with this technology because of this technology we need to shift out of that and we need to be aware enough to know what we are doing in order to do that until you make the unconscious conscious it will direct your life and you will call it fate. We have the opportunity because of this incredible technology that we're all working on. If we're aware enough, we can actually not just repeat the stuff that we have built just over here. We have the ability and the opportunity to genuinely change things and redesign things at many, many different levels that get to benefit us personally, that get to benefit us as a collective, that get to benefit us hopefully for generations to come. A lot of responsibility. But what it also does, when you're self-aware and when, and we're leading into this. Oh, my God, I'm going so slow. Okay. You can access like higher core needs, right? Those take a photo of that because those are important. When you're stressed, you do not think about those things. You think about how can I get mine? How can I satisfy my base, base needs? And you make bad decisions when you're stressed. You make decisions out of survival. Now, if we think people are in charge of billions of dollars and building technology that can genuinely change lives, we don't want them making bad decisions because they're stressed. We don't want them making bad decisions because they're not aware that they have some sort of child-based wound that makes them want to extract money versus build something that is better. So this is important. So like, yeah, read it later. This was a poll that I did for ACC where it gives you some stats about where our community is. If you see most people are feeling not great, anxious, meh, tired. Some people are feeling good, which is good. But also these are some of the challenges that are incredible stressors for our nervous systems. And these are very, very real elements of our ecosystem. Like that can put you into intense stress. And we need to be mindful of that. And we need to make sure that the people building in this ecosystem have ways of dealing with these things or we as an ecosystem are dealing with those things and are aware of those things. Burnout, that was also me. So 70% said they burnt out at least once. So that's not good. Anxiety is on the daily most of the time, so again, a very, very important factor, especially when we want this to be something that the talented humans are building in this ecosystem, kind of do it more than a year or two. You get the gist. Okay, sorry, do you want to take a photo? I mean, do it quick. But you get it. So again, this was something that I did at ECC, and this would be the practical thing that I'm suggesting. So a human protocol that's like, puts the focus on the humans behind the tech. Because I think there should be a base protocol, a base layer protocol that focuses on the humans. If we want all of us here to continue being creative, to continue having energy to do this, to continue making decisions from a higher value place, we need to have regulated nervous systems. And we need to be aware of what it is that we're doing, why we're driving certain things, why we're making certain decisions, how we're making those decisions. And I think this needs to be implemented the same way as we talk about tech protocols. A human protocol is as important as far as I'm concerned. These are the benefits and the purpose and the vision, obviously. And here, just because when you talk about therapy or talk about anything like this, it's very scary. I'm not saying that people are crazy, although a lot of us are. But these are kind of the stages. You don't have to go full ham on like get everybody on the team therapy. You can start very small, like a pilot, and then implement it, and then grow from there in stages, which I think is, again, a very, very important thing to do something gradual because, again, not everybody is comfortable with a lot of things when it comes to therapy, when it comes to stress management, when it comes to, again, regulating a nervous system. Most people don't know how to do that, and it's an important, very important tool to have. And then, yeah, this is a great meme. I made it. And then, yeah, thank you. How much older was I?",
- "eventId": "devcon-7",
- "slot_start": 1731487800000,
- "slot_end": 1731488400000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1gUdSnWcxJdTYFT1JrkVP_VWgSxrlBCcEuwRk8pzgBSA",
- "resources_slides": null,
"speakers": [
- "simona-pop"
- ]
+ "simon-emanuel-schmid",
+ "rob-stupay",
+ "abena"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731465900000,
+ "slot_end": 1731471300000,
+ "slot_roomId": "classroom-e",
+ "resources_presentation": "https://docs.google.com/presentation/d/1obE94TKOOHTvht_bjpYs85KpbFc9Qw-AagmzvQTXrYk"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -883433,8 +881532,6 @@
0,
0,
0,
- 6,
- 0,
0,
0,
0,
@@ -883916,6 +882013,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -883978,6 +882076,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -883998,11 +882098,13 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -884047,6 +882149,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -884095,6 +882198,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -884153,6 +882257,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -884531,6 +882636,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -884544,14 +882650,12 @@
0,
0,
0,
+ 2,
0,
0,
0,
0,
0,
- 2,
- 0,
- 0,
0,
0,
0,
@@ -884562,45 +882666,57 @@
},
{
"session": {
- "id": "your-intuition-antoine-flute-and-didgeridoo",
- "sourceId": "B8SMVZ",
- "title": "Your intuition Antoine flute and didgeridoo",
- "description": "Join us at the Music Stage in the social area on Floor G for an unforgettable experience with the Open Source Orchestra! Dive into the beats and vibes curated by talented musicians from the Ethereum ecosystem, bringing together community, creativity, and rhythm. Let’s groove and connect through the universal language of music!",
- "track": "Entertainment",
- "type": "Music",
- "expertise": "",
+ "id": "zk-email-fast-proofs-and-production-ready-account-recovery",
+ "sourceId": "WNQBQH",
+ "title": "ZK Email: Fast Proofs and Production-Ready Account Recovery",
+ "description": "We discuss progress that ZK Email has made in making new proofs really easily, as well as interesting new on-chain directions for email-triggered transactions. We'll go over proof registries, email-based multisig signers, and email guardians for account recovery in production.",
+ "track": "Applied Cryptography",
+ "type": "Talk",
+ "expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
- "tags": [],
+ "tags": [
+ "Privacy",
+ "ZKP",
+ "Use cases of cryptography",
+ "client-side",
+ "2FA",
+ "Account Abstraction",
+ "Cryptography",
+ "Identity",
+ "Privacy",
+ "Recovery",
+ "Security",
+ "Use cases of cryptography",
+ "Zero-Knowledge",
+ "ZKP"
+ ],
+ "keywords": [
+ "ZK",
+ "Email"
+ ],
+ "duration": 1518,
"language": "en",
- "speakers": [],
+ "sources_swarmHash": "a94b9dc27784f47de11b6a11d62b5643a1cf29f711ee569154584f599c98f857",
+ "sources_youtubeId": "YvzdNMpynZM",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734245e9dbb7a90e18aa264.vtt",
+ "transcript_text": " Today we'll mostly be talking about zkEmail, new applications, and production-ready account recovery. I'm Ayush. I'm Soran. And most of this work was only made possible because of this incredible team of folks we have working with us. So huge shout out to them. So we'll start by mostly going over the basics. What is ZK email? How does it work? Then we'll dive a little bit into how you can make proofs really easily. And we'll discuss a new registry in SDK that lets you do that. And we'll try to expand the possibilities for how you think ZK email proofs can be used in reality. Finally, we'll talk about account recovery and how you can generally have email-triggered transactions on-chain. And last, we'll talk about dev tooling. All the different ways that we've put together tools for people to build these kinds of proofs really easily into existing apps. So to start with the basics, what is ZK email? The idea is that emails are signed according to the DKIM protocol, an RSA signature of the SHA-256 of the content of the email. This is applied to every single email sent or received since 2017, usually used for spam filtration, but we prove this inside of a ZK proof and add selective disclosure and parsing. This means that we can get proofs of emails where we can get privacy, as in we can hide or reveal whatever we want. We get provenance. We can verify the data from the Web2 services mail server directly, and it's portable. We can verify it directly on chain, on any chain that can verify these proofs. You can imagine the simplest intuition for this is something like whistleblowing. We take an email you've already received and we redact different parts of the email and then we prove that the email was still valid or sent by the source. But you can do much more than this. For instance, zkp2p builds marketplaces on top of these emails. One example is a domain marketplace. The idea is that you can take any Namecheap domain that you own, and you can list it on this marketplace, and when you sell the domain to somebody, aka you transfer it to them, both of you receive a confirmation email from Namecheap automatically. If you prove that confirmation email on-chain, you can then unlock escrowed money directly to pay for that domain. This is quite compelling, and the idea that you can interoperate these Web2 assets or things in the real world with things on-chain is extremely compelling, and how can we get more of these? So our idea was, what if we made it really, really easy for somebody to create new proofs and update those proofs? So we'll talk a little bit about how this can be applied to general proof infrastructure in a couple of different ways. A registry that lets you reuse proofs that other people have already defined and define new ones very easily. An SDK that lets you use them very easily in your application. And finally, some inspiration on what are some apps that people are actually building with this. So one of the main problems with ZK development today is that an app developer who's trying to build something related to their email should not have to think about the nitty-gritty details of which proof system they're using and the different trade-offs and different systems. So the idea is you can abstract this all away. You just define a sort of a blueprint, like, oh, I want to prove that I was rejected from giving a DevCon talk, for instance. And then if I define this kind of blueprint, anybody can use it without having to think of the proof system that's happening in the background. How does this work? The idea is you can create new patterns very easily. For instance, after naming your pattern and uploading a sample email, we can automatically parse out the relevant information from that email to help define this new kind of pattern. For instance, we can take out the sender domain automatically or things like the email length of the header or the body. Then we have this nice feature where because we want to define a regex to extract specific information from within that email, we automatically throw an AI on top of that raw email data and define that regex for users. We found that historically this has been a bit of a roadblock because having to adapt regexes to odd different kinds of email templates is often not a very intuitive task, but we're hoping this makes it super easy for anyone to define a new kind of proof with no relevant ZK or necessarily even parsing experience. And finally, it'll give you a configuration like this. This is a decent amount of text, but the main thing to take away from this is that it's only about 20 or 25 lines. This defines all of your regexes, where they occur, and who the email was sent from, and other metadata about it. But this is a full encapsulation and definition of your proof. Then in the background, we can automatically compile this to all the proof systems that we listed. Right now we have Sircom and Noir Incoming and also ZKVMs. And once it's completed, the compilation is completed, we automatically will deploy an interface that anybody can use to create this proof. We see this kind of like almost like a bit of a Vercel. You can sort of create your proof and deploy it without having to think about any of the infrastructure behind the scenes. Concretely, for instance, for the proof of DevCon rejection, you will automatically get an interface for you where you can automatically sign in with your email and then it will fetch the relevant emails that might possibly satisfy this proof. We can filter those emails entirely client-sized so that our server never sees those emails, and then let the user choose the proof they want to select to make a proof of. In this case, for instance, for GitHub, for DevCon, you can choose one of the specific DevCon rejection emails. For GitHub, you could choose, for instance, a GitHub username email to let you prove your GitHub username. Finally, the proof can happen in the background, and you can share that proof out to whoever you want to share. And we also show you the metadata very clearly and even let you look at the raw proof. The idea is that once we have these kinds of definitions, we can expand this even one step further. We can also kind of treat it like a bit of a GitHub, where each of these configurations can be edited and modified by other people, and you maintain a version history. So for instance, you can imagine that each of these patterns come with versions depending on email templates as they change, or users as they want to parse different kinds of things. And if you decide, hey, I don't like this pattern, I want to replace it with a different one, say I want to take my DevCon rejection email, and instead I want to prove DevCon acceptance, I can just fork it, change that value, and recompile it. And so we see these kinds of flows that developers are very used to also being useful for general people to be able to create these new kinds of proofs. You can try this out live if you go to registry.zk.email. We've put a QR code up. You can define a new proof by logging in and then creating a new pattern or trying any of the existing ones within the interface. Note that there will probably be a decent amount of load as all the folks in the audience try this, but we will have a workshop tomorrow where we go through detail, step-by-step, how exactly to do this. Now, if you want to integrate this into an actual application, again, you don't need to read the code, but just the idea that this can just be three or four lines, someone can just define, this is the kind of blueprint that I want to prove within my app. In this case, the DevCon rejection proof. They can say if they want to be local or not, and then they can, again you don't have to read the code, but they can just generate the proof and verify it on-chain if they want without having to think about the proof system. We've seen people build a lot of really exciting stuff with just this primitive. For instance, folks have built proof of DocuSign or HelloSign where you prove you signed some document with some title from somebody. You can prove you took a flight to or from somewhere and only reveal where you took it from and the destination. Someone created this proof where you can prove you're part of a Slack workspace. You can now start seeing how these things might start combining. You can build a system where you prove you're part of an organization on Slack, and then you automatically get reimbursed for your flights by proving you took them. And as people start realizing, oh, you can bolt these things together, you can build actually interesting systems on chain where you combine different facets of ideas or identities or actions we've taken in the real world. People have also proved, for instance, you've exported your LinkedIn data, which they then sell to, for instance, OpenAI to train on. You can then prove you exported all of your OpenAI chat data and then sell it to, for instance, Anthropic. You can also prove you automatically resolve the GitHub issue and then automatically disperse contributors for their contributions. John did this fun proof where you can prove you ordered a Pad Thai in Thailand where you basically show you have a grab receipt which has the word Pad Thai on it and a location that's in Thailand. And of course, you can prove that your proposal was rejected from DEF CON. So now that we have all of these basic concepts around how you can make proofs of emails that you've received in your inbox, one might imagine that you can also make proofs directly on chain. So far, we've just talked about identity that already exists in Web 2.0. But emails, you can imagine, are an interesting interface to actually interact with on-chain. So far we've just talked about parts of your identity that already exist in Web2, but emails you can imagine are an interesting interface to actually interact with on-chain apps directly. So concretely, how might you get this new kind of email trigger transaction? Well the idea is that instead of doing what we were doing earlier where you log in with email for instance and you select one to make a proof of, you instead send an email to trigger a transaction on-chain. This is quite interesting because now you can have a smart contract that's directly gated just by a sent email. This primitive is quite powerful. You can build things like account recovery, for instance, where you add emails as wallet guardians directly on your existing smart accounts. Things like email signers, where you can add an email directly on your multi-sig and have that approve transactions, for instance, as a 2FA, or for folks who don't have EOA wallets to be able to still approve transactions. You can log in with emails. This is something folks have wanted in the ecosystem for a very long time. But the idea that you can interact with, for average, application or crypto app just by logging in with your email and then using that to authorize an ephemeral session key. Or an email wallet where you can receive assets directly to email addresses even if they've never signed up. But today, we'll mostly focus on, I guess to start with, exactly how we can do these kinds of smart contracts with emails. So for instance, the flow here is that users can receive some email asking them to trigger some kind of transaction. And by replying to it, they can initiate that transaction on-chain. They will receive an email kind of like this. We've moved the actual value that's getting approved to the subject, so it's easy for you to read. But the idea is that you would receive a command kind of like recover account eth address from old owner eth address to new owner eth address. In reality, users would just see a simulation in their email, not this text, but we've put it here so it's easy to read. And the idea is that by replying to this email, they're effectively signing this message, which can then be used to send on-chain. Flow here is that a user will try to trigger some sort of transaction, a relayer will send them an email. When they reply to that email, action is then sent directly by the relayer on-chain as they make a ZK proof of that action. One of the cool properties of this is the idea that we have this account code for both privacy and decentralization. You can kind of see, again, we've elevated it into the subject here, but normally this would just be embedded into the body where the user doesn't have to think about it. But what is the point of this long hex string? It's not really private key or something we're necessarily exactly used to. And anyway, it's abstracted away from the user. But it is nice because this value gives us direct email address privacy on-chain. We never reveal the email address, we only ever reveal a hash of the email address and that code. We can also prove availability to the user in this email. That is, concretely, we can ensure that the access to the user's account cannot be withheld by us going malicious, because as long as they have the account code, they can still transact with that email contract. And finally, it allows for relayer decentralization. Anyone can run this kind of system, can run email servers that send out emails, receive replies, and then trigger transactions on-chain. You can imagine this can happen via email replies, as it does right now, or even directly via Google logins. The difference between these is mostly basic security. For instance, on the left side, you can show concrete simulation data to the user of what they're signing. For Google sign-in, it's more like a blind sign-in and a blind signature. But the idea is that applications can choose whatever they want based on what is most convenient for them. Okay, so from now, amongst the products using email trigger transactions, here we introduce the details of the email account recovery. So in short, using email account recovery, you can specify anywhere with an email address as a guardian for your wallet. And when you lose access to your private key, this guardian can help recover your account just by sending emails. And in this way, this achieves a similar UX as a bank account or PayPal, such that users can reset passwords from their email account. And we also believe the combination of the email account recovery with the PASC wallet makes a super easy wallet UX because PASC allows users to sign transactions through the face ID and so on. And when users lose a device, users can use email account recovery to recover users recovery user's account on the other device. So from now, we explain the details of how email account details of how email account recovery works with showing the UI of the email account recovery feature in the Clive wallet we are building now. So in the first step, the user configures recovery settings, such as Guardian information. So in the Clave URL, the user just needs to specify the Guardian's email address, like this one. So in the second step, the Guardian will accept this request. So the Guardian will receive an email like this one from the relayer, and if the guardian can approve this request, the guardian just need to reply to this email. And the guardian will finally receive a confirmation email like this one. And in this process, our guardian actually generates ZK proof of the guardian's email, and send this email proof on-chain to register Guardian's address. And once the user loses access to the private key, we actually start the recovery process. So in this process, the user puts the Guardian's email address again, and the Guardian will receive an email from the layer in the same way. And if the Guardian approves this recovery request, the Guardian will reply to this email and receive the confirmation email. And in this process, the layer similarly generates ZK proof of the Guardian's email. In the final step, the Guardian, the wallet user, can complete this recovery request once more than a threshold number of the Guardian's upload recovery request. However, there is a time delay before completing this recovery request. And this improves the security when the Guardian's email account is hacked, because the wallet user can cancel recovery requests if the email account is hacked. So in this way, we can keep the security and the accessibility of the user's account as long as the user can access to the private key or the Guardian's email account is honest. Sweet. So we have those account recovery deployments audited and live on mainnet for both Clave, which we'll roll out in the Clave wallet over the next week for PASCII wallets, and also in our recovery UI for safes. But this can be larger than just a couple of wallets. The idea is that any smart wallet can integrate this into their wallet. And so we've created a bunch of dev tooling to make it really easy for anybody to use these kinds of proofs. Concretely, for instance, a recovery module is a 7579 compatible smart account standard. This means any wallet is really easy to integrate with this specific account recovery. And even if you're not 7579 compatible, it's still quite easy to add account recovery to your wallet. We have a set of very simple APIs that users can call. Again, you don't need to read all the details here. But to trigger each of these requests, you can simply hit each of those APIs, and your own wallet or your own application can trigger any of these kinds of transactions directly. And finally, installing it to any kind of wallet in a front-end is also very easy. Again, you don't have to read the exact code, but just the idea that installation is just five lines in, for instance, the permissionless JS smart wallet creation interface. You can read more about it on our docs on the right side, and we'll have more links at the end. If you want to define your own kinds of proofs, not account recovery, but say any of the other application ideas, you can define your own kind of pattern in Solidity directly. Here we show that you can say something like recover account ETH address to new owner ETH address. Once you've defined this kind of Solidity code, you can then hit any API that any relayer has deployed. The API request looks kind of like this. Again, the main thing here is it's just about 10 lines, and it'll automatically handle sending the emails for you, getting the response, making the ZK proof, and sending it on-chain. You can see, again, these docs for how exactly to build with this dev tooling over here, and we'll have a workshop tomorrow where we go over more of it in detail. So, for instance, you can imagine this abstraction can be used to build account recovery, email signers, login, and the email wallet primitive we talked about in the beginning, but we're excited for folks to explore with these kind of email trigger transactions to build more different kinds of things. So just to quickly recap, we went over the very basics of how ZK email works and simple kinds of proofs you can make, how to make new kinds of proofs very easily and access them from a shared registry. Then, switching from making proofs of received emails to making new kinds of proofs very easily and access them from a shared registry, then switching from making proofs of received emails to making proofs of sent emails, we went over how you can do email trigger transactions, and then account recovery, and finally how we've made this really easy for new folks to either directly use or integrate directly into their wallets or projects, etc. We're super excited to jam more with folks. If people want, we'll have some booths specified on the left. You can catch us there after this talk and also over the next two days. And if you want to learn more about how to specifically use these tools in your applications, we'll have a concrete workshop tomorrow at 1.30 p.m. where we go over how to actually integrate each of these things directly with help from the team who actually built it. Sweet. So if you want to read, see, or hear more, we recommend following our Twitter on the left side, looking at our home page in the middle on zk.email. And if you want to view an original copy of these slides, you can scan the QR code on the rightmost side. Sweet. Thank you for coming, and we'll take some questions. Sweet. Thank you, Ayush and Sora. That was a very interesting talk, by the way, right? Yeah, I like to see ZKPs being used for something else rather than ZK all apps, right? And it makes us both Web 2 and Web 3. So we have some time for Q&A. So how about we take the first one? So it says, what zkp framework you are using and why? Yeah, it's a good question. So we've used and benchmarked all of the frameworks that we kind of listed in the beginning. We have versions in Surcom and now Noir and also now in ZKVMs like SP1 and RISC-0. We generally, so because most of these things are happening on, for instance, mainnets, we want to make sure that there's both high security and extremely high speed. So currently we use Surcom on the server side and also on the client side just because it's kind of the main one that's very mainnet ready right now, and also can prove extremely fast on the server side, and within like five to ten seconds usually for most of the proofs we're talking about. But we intend to work closer with Noir to get those client side proofs working in Noir, and closer with the ZKVMs to get much more extensible proofs on the server side. Yeah, that makes sense. Actually, by the way, you can upvote the questions so that we can see those that you upvoted first here on the screen. So maybe if we take the second one, would trusted setup ceremonies ever be required? If so, when? Yeah, so this sort of depends on the exact proof system you're using. If you're using the CIRCOM proof system we have in production right now, then yes, you will need to do a trusted setup. However, if you use the Noir system on the client side we're moving to, or the ZKVM system on the server side that we also have, then you won't need to do a trusted setup for that specific circuit. Yeah, so we have two votes. Yeah, maybe this question. So is there any prerequirements for an email to be ZK-approved? Not really. Any email you send to receive can usually be ZK-approved because all emails require this DKIM signature to go through spam filtration. There are some restrictions, like, for instance, Hotmail is not exactly pursuant to the standards, so something that you can't access a two-email within a Hotmail is not exactly pursuant to the standards, so some things that you can't access to email within a Hotmail email. But in general, almost every email that you send or receive can be approved. Okay, gotcha. I think we've still got time for more questions. Yeah. Yeah, maybe this one, when we consider... I think we can see them also here. I guess the top one, is there a key rotation problem? Yeah, so the public keys that the verification actually happens with are rotated every maybe six months to two years. For some folks, it never rotates. The nice thing about this is that the smart contract that holds those keys is publicly auditable. Anybody can go in and say, yep, this is the key that my DNS is fetching as well. But yes, to relay those keys on publicly auditable. Anybody can go in and say, yep, this is the keys that my DNS is fetching as well. But yes, to relay those keys on-chain, there has to be some sort of a system of oracles. In our case, we use like a specific multi-sig in which all of the, like a bunch of autonomous computers are calculating those and putting it on-chain. You can also doubly verify TLS notary or TLS proxies to ensure that all those values are correct. The important thing here is that you can use a single public value, that DNS value, to verify private data. And that public value is auditable. So the idea is that if there was ever some fault, somebody pushed malicious keys, there are enough time locks built into the system and also ways to stop it or ways to override those key registries for each user that we think this is not actually that big of a problem in practice. That makes sense. Thank you for the detailed question. Yeah, so maybe what if we take this one? Since DKIM private keys for the whole domain rather than the percenter, presumably the security model relies and we don't see the question anymore. Yeah, so, so... I mean, I'm just repeating the question for the live stream so that people, yeah, so the origin MTA preventing sender spoofing within the domain. Yeah, so the idea here is that yes, because you're only verifying the signature from the domain, you are trusting that that specific domain is, in fact, disambiguating senders correctly. The nice thing here is that most email providers that most people use, like Gmail, Outlook, iCloud, et cetera, definitely have this in by default because it would be very bad if they didn't. But we have noticed that some folks don't. So, for instance, we disable most .edu domains from most of these models because often they don't have very good parsing of this kind of which sender exactly in the domain sent that email. But in most cases, for instance, that you receive an email from Twitter or DevCon or whatever, usually you can constrain exactly the email address that sent it, and that's usually good enough. And they're usually using something like Google Workspace, so it's usually good enough, and they're usually using something like Google Workspace, so it's usually possible. And in the context of the email trigger transactions, while this depends on the private key of the specific email or Deacon or server like Gmail, we believe this achieves a better trade-off between the UX and the security. Thank you. So I think we are on time. Please thank again Ayush and Sora and please applaud them for their talk.",
"eventId": "devcon-7",
- "slot_start": 1731389400000,
- "slot_end": 1731391200000,
- "slot_roomId": "music-stage",
- "resources_presentation": "https://docs.google.com/presentation/d/1y6uMrtpD3uRb_lrG6TXEsSK_UJ8-x7X4UM7zvdFJaIY"
+ "slot_start": 1731468600000,
+ "slot_end": 1731470400000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1G6_OH46sVVpOgDR1P1ZWqOpTtRzjcESBO1p9aHuVisY",
+ "resources_slides": null,
+ "speakers": [
+ "aayush-gupta",
+ "sora-suegami"
+ ]
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -884611,6 +882727,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -884714,6 +882831,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -885343,10 +883461,12 @@
0,
0,
0,
+ 6,
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -885358,6 +883478,8 @@
0,
0,
0,
+ 6,
+ 6,
0,
0,
0,
@@ -885372,6 +883494,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -885392,7 +883515,9 @@
0,
0,
0,
+ 2,
0,
+ 2,
0,
0,
0,
@@ -885416,6 +883541,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -885456,6 +883582,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -885506,6 +883633,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -885892,6 +884020,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -885900,6 +884030,7 @@
2,
0,
0,
+ 0,
2,
0,
0,
@@ -885918,53 +884049,42 @@
},
{
"session": {
- "id": "zero-to-dapp",
- "sourceId": "LUW7G9",
- "title": "Zero To Dapp",
- "description": "Learning Web3 programming. There are so many different tools and protocols to learn. Zero to Dapp is a workshop series that builds upon collaboration between different projects to guide the students from zero to their first Dapp. In this workshop, we review our learning from previous editions to encourage others give their own Zero to Dapp. Then we'll give a shortened version - usually, this workshop takes between a half day up to two full days. But we are fast learners at DevCon, aren’t we? ;)",
- "track": "Developer Experience",
- "type": "Workshop",
- "expertise": "Beginner",
- "audience": "Developer",
+ "id": "zk-in-rollups-full-validity-proving-on-the-op-stack",
+ "sourceId": "8J8Z7Q",
+ "title": "ZK in Rollups: Full Validity Proving on the OP Stack",
+ "description": "Historically, zkEVM rollups have been difficult to build, requiring deep cryptography expertise that makes customization and maintainability complicated and time-consuming. With advancements in zk, zkVMs make it easy for any developer to write ZK applications with Rust. With a zkVM, we've created seamless way to upgrade ANY existing OP Stack chain to use ZKPs in just 1 hour. These rollups get fast finality, cost-effective (<0.1 cent / tx), and full EVM equivalence.",
+ "track": "Layer 2",
+ "type": "Talk",
+ "expertise": "Intermediate",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [
- "Onboarding"
- ],
+ "keywords": [],
"tags": [
- "Layer 1",
"Layer 2s",
- "Tooling",
- "DevRel",
- "Live Coding",
- "onboarding",
- "DevRel",
- "Layer 1",
- "Layer 2s",
- "Live Coding",
- "Tooling"
+ "Rollups",
+ "ZKP"
],
"language": "en",
"speakers": [
- "simon-emanuel-schmid",
- "rob-stupay",
- "abena"
+ "uma-roy"
],
"eventId": "devcon-7",
- "slot_start": 1731465900000,
- "slot_end": 1731471300000,
- "slot_roomId": "classroom-e",
- "resources_presentation": "https://docs.google.com/presentation/d/1obE94TKOOHTvht_bjpYs85KpbFc9Qw-AagmzvQTXrYk"
+ "slot_start": 1731582600000,
+ "slot_end": 1731583800000,
+ "slot_roomId": "stage-5",
+ "resources_presentation": "https://docs.google.com/presentation/d/1Dw9W_WUh2DLUhcVkatH257BHYs8yWdxlfLhoJXs8jnY"
},
"vector": [
0,
0,
0,
- 6,
0,
0,
0,
0,
+ 6,
+ 0,
0,
0,
0,
@@ -886640,7 +884760,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -886702,7 +884821,6 @@
0,
0,
0,
- 6,
6,
0,
0,
@@ -886724,14 +884842,11 @@
0,
0,
0,
- 6,
0,
0,
0,
0,
0,
- 2,
- 0,
0,
0,
0,
@@ -886752,6 +884867,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -886784,6 +884900,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -886824,7 +884941,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -886883,7 +884999,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -887262,7 +885377,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -887287,59 +885401,53 @@
0,
0,
0,
+ 0,
+ 0,
0
]
},
{
"session": {
- "id": "zk-email-fast-proofs-and-production-ready-account-recovery",
- "sourceId": "WNQBQH",
- "title": "ZK Email: Fast Proofs and Production-Ready Account Recovery",
- "description": "We discuss progress that ZK Email has made in making new proofs really easily, as well as interesting new on-chain directions for email-triggered transactions. We'll go over proof registries, email-based multisig signers, and email guardians for account recovery in production.",
+ "id": "zkmpc-bring-public-auditability-into-mpc",
+ "sourceId": "XNN3XR",
+ "title": "ZKMPC: Bring public auditability into MPC",
+ "description": "In multi-party computation (MPC), participants collaboratively compute without revealing private inputs. To secure MPC on a blockchain, preventing collusion is essential. We developed a \"publicly auditable\" version of SPDZ, a widely-used MPC protocol, that enables third-party verification through zero-knowledge proofs (ZKP) collaboratively generated by multiple parties. We will also demonstrate application examples, such as a Game Master-free werewolf game.",
"track": "Applied Cryptography",
"type": "Talk",
"expertise": "Intermediate",
- "audience": "Engineering",
+ "audience": "Research",
"featured": false,
"doNotRecord": false,
"tags": [
- "Privacy",
"ZKP",
- "Use cases of cryptography",
- "client-side",
- "2FA",
- "Account Abstraction",
- "Cryptography",
- "Identity",
- "Privacy",
- "Recovery",
- "Security",
- "Use cases of cryptography",
- "Zero-Knowledge",
+ "MPC",
+ "collaboration",
+ "zk-snark",
+ "MPC",
"ZKP"
],
"keywords": [
- "ZK",
- "Email"
+ "Collaborative",
+ "zk-SNARKs"
],
- "duration": 1518,
+ "duration": 1399,
"language": "en",
- "sources_swarmHash": "a94b9dc27784f47de11b6a11d62b5643a1cf29f711ee569154584f599c98f857",
- "sources_youtubeId": "YvzdNMpynZM",
+ "sources_swarmHash": "84b05559d4df707a8f29bbb79e18bb1bdb1fff62ae2738288c7d4be463f3b188",
+ "sources_youtubeId": "aWQ8zzi1EAQ",
"sources_ipfsHash": "",
"sources_livepeerId": "",
"sources_streamethId": null,
- "transcript_vtt": "https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6734245e9dbb7a90e18aa264.vtt",
- "transcript_text": " Today we'll mostly be talking about zkEmail, new applications, and production-ready account recovery. I'm Ayush. I'm Soran. And most of this work was only made possible because of this incredible team of folks we have working with us. So huge shout out to them. So we'll start by mostly going over the basics. What is ZK email? How does it work? Then we'll dive a little bit into how you can make proofs really easily. And we'll discuss a new registry in SDK that lets you do that. And we'll try to expand the possibilities for how you think ZK email proofs can be used in reality. Finally, we'll talk about account recovery and how you can generally have email-triggered transactions on-chain. And last, we'll talk about dev tooling. All the different ways that we've put together tools for people to build these kinds of proofs really easily into existing apps. So to start with the basics, what is ZK email? The idea is that emails are signed according to the DKIM protocol, an RSA signature of the SHA-256 of the content of the email. This is applied to every single email sent or received since 2017, usually used for spam filtration, but we prove this inside of a ZK proof and add selective disclosure and parsing. This means that we can get proofs of emails where we can get privacy, as in we can hide or reveal whatever we want. We get provenance. We can verify the data from the Web2 services mail server directly, and it's portable. We can verify it directly on chain, on any chain that can verify these proofs. You can imagine the simplest intuition for this is something like whistleblowing. We take an email you've already received and we redact different parts of the email and then we prove that the email was still valid or sent by the source. But you can do much more than this. For instance, zkp2p builds marketplaces on top of these emails. One example is a domain marketplace. The idea is that you can take any Namecheap domain that you own, and you can list it on this marketplace, and when you sell the domain to somebody, aka you transfer it to them, both of you receive a confirmation email from Namecheap automatically. If you prove that confirmation email on-chain, you can then unlock escrowed money directly to pay for that domain. This is quite compelling, and the idea that you can interoperate these Web2 assets or things in the real world with things on-chain is extremely compelling, and how can we get more of these? So our idea was, what if we made it really, really easy for somebody to create new proofs and update those proofs? So we'll talk a little bit about how this can be applied to general proof infrastructure in a couple of different ways. A registry that lets you reuse proofs that other people have already defined and define new ones very easily. An SDK that lets you use them very easily in your application. And finally, some inspiration on what are some apps that people are actually building with this. So one of the main problems with ZK development today is that an app developer who's trying to build something related to their email should not have to think about the nitty-gritty details of which proof system they're using and the different trade-offs and different systems. So the idea is you can abstract this all away. You just define a sort of a blueprint, like, oh, I want to prove that I was rejected from giving a DevCon talk, for instance. And then if I define this kind of blueprint, anybody can use it without having to think of the proof system that's happening in the background. How does this work? The idea is you can create new patterns very easily. For instance, after naming your pattern and uploading a sample email, we can automatically parse out the relevant information from that email to help define this new kind of pattern. For instance, we can take out the sender domain automatically or things like the email length of the header or the body. Then we have this nice feature where because we want to define a regex to extract specific information from within that email, we automatically throw an AI on top of that raw email data and define that regex for users. We found that historically this has been a bit of a roadblock because having to adapt regexes to odd different kinds of email templates is often not a very intuitive task, but we're hoping this makes it super easy for anyone to define a new kind of proof with no relevant ZK or necessarily even parsing experience. And finally, it'll give you a configuration like this. This is a decent amount of text, but the main thing to take away from this is that it's only about 20 or 25 lines. This defines all of your regexes, where they occur, and who the email was sent from, and other metadata about it. But this is a full encapsulation and definition of your proof. Then in the background, we can automatically compile this to all the proof systems that we listed. Right now we have Sircom and Noir Incoming and also ZKVMs. And once it's completed, the compilation is completed, we automatically will deploy an interface that anybody can use to create this proof. We see this kind of like almost like a bit of a Vercel. You can sort of create your proof and deploy it without having to think about any of the infrastructure behind the scenes. Concretely, for instance, for the proof of DevCon rejection, you will automatically get an interface for you where you can automatically sign in with your email and then it will fetch the relevant emails that might possibly satisfy this proof. We can filter those emails entirely client-sized so that our server never sees those emails, and then let the user choose the proof they want to select to make a proof of. In this case, for instance, for GitHub, for DevCon, you can choose one of the specific DevCon rejection emails. For GitHub, you could choose, for instance, a GitHub username email to let you prove your GitHub username. Finally, the proof can happen in the background, and you can share that proof out to whoever you want to share. And we also show you the metadata very clearly and even let you look at the raw proof. The idea is that once we have these kinds of definitions, we can expand this even one step further. We can also kind of treat it like a bit of a GitHub, where each of these configurations can be edited and modified by other people, and you maintain a version history. So for instance, you can imagine that each of these patterns come with versions depending on email templates as they change, or users as they want to parse different kinds of things. And if you decide, hey, I don't like this pattern, I want to replace it with a different one, say I want to take my DevCon rejection email, and instead I want to prove DevCon acceptance, I can just fork it, change that value, and recompile it. And so we see these kinds of flows that developers are very used to also being useful for general people to be able to create these new kinds of proofs. You can try this out live if you go to registry.zk.email. We've put a QR code up. You can define a new proof by logging in and then creating a new pattern or trying any of the existing ones within the interface. Note that there will probably be a decent amount of load as all the folks in the audience try this, but we will have a workshop tomorrow where we go through detail, step-by-step, how exactly to do this. Now, if you want to integrate this into an actual application, again, you don't need to read the code, but just the idea that this can just be three or four lines, someone can just define, this is the kind of blueprint that I want to prove within my app. In this case, the DevCon rejection proof. They can say if they want to be local or not, and then they can, again you don't have to read the code, but they can just generate the proof and verify it on-chain if they want without having to think about the proof system. We've seen people build a lot of really exciting stuff with just this primitive. For instance, folks have built proof of DocuSign or HelloSign where you prove you signed some document with some title from somebody. You can prove you took a flight to or from somewhere and only reveal where you took it from and the destination. Someone created this proof where you can prove you're part of a Slack workspace. You can now start seeing how these things might start combining. You can build a system where you prove you're part of an organization on Slack, and then you automatically get reimbursed for your flights by proving you took them. And as people start realizing, oh, you can bolt these things together, you can build actually interesting systems on chain where you combine different facets of ideas or identities or actions we've taken in the real world. People have also proved, for instance, you've exported your LinkedIn data, which they then sell to, for instance, OpenAI to train on. You can then prove you exported all of your OpenAI chat data and then sell it to, for instance, Anthropic. You can also prove you automatically resolve the GitHub issue and then automatically disperse contributors for their contributions. John did this fun proof where you can prove you ordered a Pad Thai in Thailand where you basically show you have a grab receipt which has the word Pad Thai on it and a location that's in Thailand. And of course, you can prove that your proposal was rejected from DEF CON. So now that we have all of these basic concepts around how you can make proofs of emails that you've received in your inbox, one might imagine that you can also make proofs directly on chain. So far, we've just talked about identity that already exists in Web 2.0. But emails, you can imagine, are an interesting interface to actually interact with on-chain. So far we've just talked about parts of your identity that already exist in Web2, but emails you can imagine are an interesting interface to actually interact with on-chain apps directly. So concretely, how might you get this new kind of email trigger transaction? Well the idea is that instead of doing what we were doing earlier where you log in with email for instance and you select one to make a proof of, you instead send an email to trigger a transaction on-chain. This is quite interesting because now you can have a smart contract that's directly gated just by a sent email. This primitive is quite powerful. You can build things like account recovery, for instance, where you add emails as wallet guardians directly on your existing smart accounts. Things like email signers, where you can add an email directly on your multi-sig and have that approve transactions, for instance, as a 2FA, or for folks who don't have EOA wallets to be able to still approve transactions. You can log in with emails. This is something folks have wanted in the ecosystem for a very long time. But the idea that you can interact with, for average, application or crypto app just by logging in with your email and then using that to authorize an ephemeral session key. Or an email wallet where you can receive assets directly to email addresses even if they've never signed up. But today, we'll mostly focus on, I guess to start with, exactly how we can do these kinds of smart contracts with emails. So for instance, the flow here is that users can receive some email asking them to trigger some kind of transaction. And by replying to it, they can initiate that transaction on-chain. They will receive an email kind of like this. We've moved the actual value that's getting approved to the subject, so it's easy for you to read. But the idea is that you would receive a command kind of like recover account eth address from old owner eth address to new owner eth address. In reality, users would just see a simulation in their email, not this text, but we've put it here so it's easy to read. And the idea is that by replying to this email, they're effectively signing this message, which can then be used to send on-chain. Flow here is that a user will try to trigger some sort of transaction, a relayer will send them an email. When they reply to that email, action is then sent directly by the relayer on-chain as they make a ZK proof of that action. One of the cool properties of this is the idea that we have this account code for both privacy and decentralization. You can kind of see, again, we've elevated it into the subject here, but normally this would just be embedded into the body where the user doesn't have to think about it. But what is the point of this long hex string? It's not really private key or something we're necessarily exactly used to. And anyway, it's abstracted away from the user. But it is nice because this value gives us direct email address privacy on-chain. We never reveal the email address, we only ever reveal a hash of the email address and that code. We can also prove availability to the user in this email. That is, concretely, we can ensure that the access to the user's account cannot be withheld by us going malicious, because as long as they have the account code, they can still transact with that email contract. And finally, it allows for relayer decentralization. Anyone can run this kind of system, can run email servers that send out emails, receive replies, and then trigger transactions on-chain. You can imagine this can happen via email replies, as it does right now, or even directly via Google logins. The difference between these is mostly basic security. For instance, on the left side, you can show concrete simulation data to the user of what they're signing. For Google sign-in, it's more like a blind sign-in and a blind signature. But the idea is that applications can choose whatever they want based on what is most convenient for them. Okay, so from now, amongst the products using email trigger transactions, here we introduce the details of the email account recovery. So in short, using email account recovery, you can specify anywhere with an email address as a guardian for your wallet. And when you lose access to your private key, this guardian can help recover your account just by sending emails. And in this way, this achieves a similar UX as a bank account or PayPal, such that users can reset passwords from their email account. And we also believe the combination of the email account recovery with the PASC wallet makes a super easy wallet UX because PASC allows users to sign transactions through the face ID and so on. And when users lose a device, users can use email account recovery to recover users recovery user's account on the other device. So from now, we explain the details of how email account details of how email account recovery works with showing the UI of the email account recovery feature in the Clive wallet we are building now. So in the first step, the user configures recovery settings, such as Guardian information. So in the Clave URL, the user just needs to specify the Guardian's email address, like this one. So in the second step, the Guardian will accept this request. So the Guardian will receive an email like this one from the relayer, and if the guardian can approve this request, the guardian just need to reply to this email. And the guardian will finally receive a confirmation email like this one. And in this process, our guardian actually generates ZK proof of the guardian's email, and send this email proof on-chain to register Guardian's address. And once the user loses access to the private key, we actually start the recovery process. So in this process, the user puts the Guardian's email address again, and the Guardian will receive an email from the layer in the same way. And if the Guardian approves this recovery request, the Guardian will reply to this email and receive the confirmation email. And in this process, the layer similarly generates ZK proof of the Guardian's email. In the final step, the Guardian, the wallet user, can complete this recovery request once more than a threshold number of the Guardian's upload recovery request. However, there is a time delay before completing this recovery request. And this improves the security when the Guardian's email account is hacked, because the wallet user can cancel recovery requests if the email account is hacked. So in this way, we can keep the security and the accessibility of the user's account as long as the user can access to the private key or the Guardian's email account is honest. Sweet. So we have those account recovery deployments audited and live on mainnet for both Clave, which we'll roll out in the Clave wallet over the next week for PASCII wallets, and also in our recovery UI for safes. But this can be larger than just a couple of wallets. The idea is that any smart wallet can integrate this into their wallet. And so we've created a bunch of dev tooling to make it really easy for anybody to use these kinds of proofs. Concretely, for instance, a recovery module is a 7579 compatible smart account standard. This means any wallet is really easy to integrate with this specific account recovery. And even if you're not 7579 compatible, it's still quite easy to add account recovery to your wallet. We have a set of very simple APIs that users can call. Again, you don't need to read all the details here. But to trigger each of these requests, you can simply hit each of those APIs, and your own wallet or your own application can trigger any of these kinds of transactions directly. And finally, installing it to any kind of wallet in a front-end is also very easy. Again, you don't have to read the exact code, but just the idea that installation is just five lines in, for instance, the permissionless JS smart wallet creation interface. You can read more about it on our docs on the right side, and we'll have more links at the end. If you want to define your own kinds of proofs, not account recovery, but say any of the other application ideas, you can define your own kind of pattern in Solidity directly. Here we show that you can say something like recover account ETH address to new owner ETH address. Once you've defined this kind of Solidity code, you can then hit any API that any relayer has deployed. The API request looks kind of like this. Again, the main thing here is it's just about 10 lines, and it'll automatically handle sending the emails for you, getting the response, making the ZK proof, and sending it on-chain. You can see, again, these docs for how exactly to build with this dev tooling over here, and we'll have a workshop tomorrow where we go over more of it in detail. So, for instance, you can imagine this abstraction can be used to build account recovery, email signers, login, and the email wallet primitive we talked about in the beginning, but we're excited for folks to explore with these kind of email trigger transactions to build more different kinds of things. So just to quickly recap, we went over the very basics of how ZK email works and simple kinds of proofs you can make, how to make new kinds of proofs very easily and access them from a shared registry. Then, switching from making proofs of received emails to making new kinds of proofs very easily and access them from a shared registry, then switching from making proofs of received emails to making proofs of sent emails, we went over how you can do email trigger transactions, and then account recovery, and finally how we've made this really easy for new folks to either directly use or integrate directly into their wallets or projects, etc. We're super excited to jam more with folks. If people want, we'll have some booths specified on the left. You can catch us there after this talk and also over the next two days. And if you want to learn more about how to specifically use these tools in your applications, we'll have a concrete workshop tomorrow at 1.30 p.m. where we go over how to actually integrate each of these things directly with help from the team who actually built it. Sweet. So if you want to read, see, or hear more, we recommend following our Twitter on the left side, looking at our home page in the middle on zk.email. And if you want to view an original copy of these slides, you can scan the QR code on the rightmost side. Sweet. Thank you for coming, and we'll take some questions. Sweet. Thank you, Ayush and Sora. That was a very interesting talk, by the way, right? Yeah, I like to see ZKPs being used for something else rather than ZK all apps, right? And it makes us both Web 2 and Web 3. So we have some time for Q&A. So how about we take the first one? So it says, what zkp framework you are using and why? Yeah, it's a good question. So we've used and benchmarked all of the frameworks that we kind of listed in the beginning. We have versions in Surcom and now Noir and also now in ZKVMs like SP1 and RISC-0. We generally, so because most of these things are happening on, for instance, mainnets, we want to make sure that there's both high security and extremely high speed. So currently we use Surcom on the server side and also on the client side just because it's kind of the main one that's very mainnet ready right now, and also can prove extremely fast on the server side, and within like five to ten seconds usually for most of the proofs we're talking about. But we intend to work closer with Noir to get those client side proofs working in Noir, and closer with the ZKVMs to get much more extensible proofs on the server side. Yeah, that makes sense. Actually, by the way, you can upvote the questions so that we can see those that you upvoted first here on the screen. So maybe if we take the second one, would trusted setup ceremonies ever be required? If so, when? Yeah, so this sort of depends on the exact proof system you're using. If you're using the CIRCOM proof system we have in production right now, then yes, you will need to do a trusted setup. However, if you use the Noir system on the client side we're moving to, or the ZKVM system on the server side that we also have, then you won't need to do a trusted setup for that specific circuit. Yeah, so we have two votes. Yeah, maybe this question. So is there any prerequirements for an email to be ZK-approved? Not really. Any email you send to receive can usually be ZK-approved because all emails require this DKIM signature to go through spam filtration. There are some restrictions, like, for instance, Hotmail is not exactly pursuant to the standards, so something that you can't access a two-email within a Hotmail is not exactly pursuant to the standards, so some things that you can't access to email within a Hotmail email. But in general, almost every email that you send or receive can be approved. Okay, gotcha. I think we've still got time for more questions. Yeah. Yeah, maybe this one, when we consider... I think we can see them also here. I guess the top one, is there a key rotation problem? Yeah, so the public keys that the verification actually happens with are rotated every maybe six months to two years. For some folks, it never rotates. The nice thing about this is that the smart contract that holds those keys is publicly auditable. Anybody can go in and say, yep, this is the key that my DNS is fetching as well. But yes, to relay those keys on publicly auditable. Anybody can go in and say, yep, this is the keys that my DNS is fetching as well. But yes, to relay those keys on-chain, there has to be some sort of a system of oracles. In our case, we use like a specific multi-sig in which all of the, like a bunch of autonomous computers are calculating those and putting it on-chain. You can also doubly verify TLS notary or TLS proxies to ensure that all those values are correct. The important thing here is that you can use a single public value, that DNS value, to verify private data. And that public value is auditable. So the idea is that if there was ever some fault, somebody pushed malicious keys, there are enough time locks built into the system and also ways to stop it or ways to override those key registries for each user that we think this is not actually that big of a problem in practice. That makes sense. Thank you for the detailed question. Yeah, so maybe what if we take this one? Since DKIM private keys for the whole domain rather than the percenter, presumably the security model relies and we don't see the question anymore. Yeah, so, so... I mean, I'm just repeating the question for the live stream so that people, yeah, so the origin MTA preventing sender spoofing within the domain. Yeah, so the idea here is that yes, because you're only verifying the signature from the domain, you are trusting that that specific domain is, in fact, disambiguating senders correctly. The nice thing here is that most email providers that most people use, like Gmail, Outlook, iCloud, et cetera, definitely have this in by default because it would be very bad if they didn't. But we have noticed that some folks don't. So, for instance, we disable most .edu domains from most of these models because often they don't have very good parsing of this kind of which sender exactly in the domain sent that email. But in most cases, for instance, that you receive an email from Twitter or DevCon or whatever, usually you can constrain exactly the email address that sent it, and that's usually good enough. And they're usually using something like Google Workspace, so it's usually good enough, and they're usually using something like Google Workspace, so it's usually possible. And in the context of the email trigger transactions, while this depends on the private key of the specific email or Deacon or server like Gmail, we believe this achieves a better trade-off between the UX and the security. Thank you. So I think we are on time. Please thank again Ayush and Sora and please applaud them for their talk.",
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731468600000,
- "slot_end": 1731470400000,
+ "slot_start": 1731407400000,
+ "slot_end": 1731409200000,
"slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1G6_OH46sVVpOgDR1P1ZWqOpTtRzjcESBO1p9aHuVisY",
+ "resources_presentation": "https://docs.google.com/presentation/d/10GOrQfQ0ldlyvKU05TvdHfQd4G2zNNTzfEe2i2bfgMQ",
"resources_slides": null,
"speakers": [
- "aayush-gupta",
- "sora-suegami"
+ "task-ohmori",
+ "yusuke-nakae"
]
},
"vector": [
@@ -887458,7 +885566,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -888091,11 +886198,11 @@
0,
0,
6,
+ 6,
0,
0,
0,
0,
- 6,
0,
0,
0,
@@ -888107,8 +886214,6 @@
0,
0,
0,
- 6,
- 6,
0,
0,
0,
@@ -888123,7 +886228,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -888144,9 +886248,7 @@
0,
0,
0,
- 2,
0,
- 2,
0,
0,
0,
@@ -888170,10 +886272,10 @@
0,
0,
0,
- 2,
0,
0,
0,
+ 2,
0,
0,
0,
@@ -888187,6 +886289,8 @@
0,
0,
0,
+ 2,
+ 0,
0,
0,
0,
@@ -888211,7 +886315,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -888262,7 +886365,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -888649,14 +886751,13 @@
0,
0,
0,
- 2,
- 2,
0,
0,
0,
0,
0,
2,
+ 2,
0,
0,
0,
@@ -888665,6 +886766,10 @@
0,
0,
0,
+ 2,
+ 0,
+ 0,
+ 0,
0,
0,
0,
@@ -888678,31 +886783,50 @@
},
{
"session": {
- "id": "zk-in-rollups-full-validity-proving-on-the-op-stack",
- "sourceId": "8J8Z7Q",
- "title": "ZK in Rollups: Full Validity Proving on the OP Stack",
- "description": "Historically, zkEVM rollups have been difficult to build, requiring deep cryptography expertise that makes customization and maintainability complicated and time-consuming. With advancements in zk, zkVMs make it easy for any developer to write ZK applications with Rust. With a zkVM, we've created seamless way to upgrade ANY existing OP Stack chain to use ZKPs in just 1 hour. These rollups get fast finality, cost-effective (<0.1 cent / tx), and full EVM equivalence.",
- "track": "Layer 2",
+ "id": "zkpassport-private-unforgeable-identity",
+ "sourceId": "K3GWST",
+ "title": "ZKpassport: Private Unforgeable Identity",
+ "description": "This talk presents ZKpassport, an identity verification solution integrating zero-knowledge proofs with ePassports to achieve privacy-preserving and unforgeable government-attested digital identities. We will delve into the technical architecture, implementation challenges, and practical applications. Attendees will gain insights into the development process, benefits, and potential uses of this technology in enhancing digital identity privacy and security.",
+ "track": "Applied Cryptography",
"type": "Talk",
"expertise": "Intermediate",
"audience": "Engineering",
"featured": false,
"doNotRecord": false,
- "keywords": [],
"tags": [
- "Layer 2s",
- "Rollups",
- "ZKP"
+ "Privacy",
+ "Identity",
+ "Zero-Knowledge",
+ "noir",
+ "Identity",
+ "Privacy",
+ "Zero-Knowledge"
],
- "language": "en",
- "speakers": [
- "uma-roy"
+ "keywords": [
+ "ZK",
+ "NFC",
+ "Noir",
+ "PLONK"
],
+ "duration": 1189,
+ "language": "en",
+ "sources_swarmHash": "8ff112bba1682d13788042e5ab586ab285935e607ec2031734b6ed5acbad29ea",
+ "sources_youtubeId": "W6C-duDEiOU",
+ "sources_ipfsHash": "",
+ "sources_livepeerId": "",
+ "sources_streamethId": null,
+ "transcript_vtt": "No VTT link provided",
+ "transcript_text": "No transcript text provided",
"eventId": "devcon-7",
- "slot_start": 1731582600000,
- "slot_end": 1731583800000,
- "slot_roomId": "stage-5",
- "resources_presentation": "https://docs.google.com/presentation/d/1Dw9W_WUh2DLUhcVkatH257BHYs8yWdxlfLhoJXs8jnY"
+ "slot_start": 1731484200000,
+ "slot_end": 1731486000000,
+ "slot_roomId": "classroom-a",
+ "resources_presentation": "https://docs.google.com/presentation/d/1oOW6cu6Z74Nvx5lSpva4kFP8hggWPnZdL6MvVt9Hc9U",
+ "resources_slides": null,
+ "speakers": [
+ "michael-elliot",
+ "theo-madzou"
+ ]
},
"vector": [
0,
@@ -888712,15 +886836,10 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -888879,8 +886998,10 @@
0,
0,
0,
+ 6,
0,
0,
+ 6,
0,
0,
0,
@@ -889453,7 +887574,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -889470,6 +887590,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -889499,7 +887620,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -889507,6 +887627,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -889523,7 +887644,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -889532,7 +887652,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -889558,6 +887677,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -889574,6 +887694,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -890040,55 +888161,43 @@
},
{
"session": {
- "id": "zkmpc-bring-public-auditability-into-mpc",
- "sourceId": "XNN3XR",
- "title": "ZKMPC: Bring public auditability into MPC",
- "description": "In multi-party computation (MPC), participants collaboratively compute without revealing private inputs. To secure MPC on a blockchain, preventing collusion is essential. We developed a \"publicly auditable\" version of SPDZ, a widely-used MPC protocol, that enables third-party verification through zero-knowledge proofs (ZKP) collaboratively generated by multiple parties. We will also demonstrate application examples, such as a Game Master-free werewolf game.",
- "track": "Applied Cryptography",
+ "id": "zkproving-the-history-of-ethereum-in-real-time",
+ "sourceId": "TVNJ99",
+ "title": "zkProving the history of Ethereum in real time.",
+ "description": "I'll explain the current work that we are doing in the Polygon zk teams to improve the performance of the provers and the quality of the tooling.\r\nI'll will explain how we can parallelise the generation of the proof and how we can integrate with different hardware and software so that it should allow to build a zk proof of a block in real time. \r\nI'll explain also how this proofs can be recursively linked to build a zkProof that can proof the whole Ethereum history from the genesis.",
+ "track": "Core Protocol",
"type": "Talk",
- "expertise": "Intermediate",
- "audience": "Research",
+ "expertise": "Expert",
+ "audience": "Engineering",
"featured": false,
"doNotRecord": false,
+ "keywords": [
+ "Lightclient",
+ "type1",
+ "STARK"
+ ],
"tags": [
+ "ZK-EVMs",
"ZKP",
- "MPC",
- "collaboration",
- "zk-snark",
- "MPC",
+ "Zero-Knowledge",
+ "lightclient",
+ "type1",
+ "starks",
+ "Zero-Knowledge",
+ "ZK-EVMs",
"ZKP"
],
- "keywords": [
- "Collaborative",
- "zk-SNARKs"
- ],
- "duration": 1399,
"language": "en",
- "sources_swarmHash": "84b05559d4df707a8f29bbb79e18bb1bdb1fff62ae2738288c7d4be463f3b188",
- "sources_youtubeId": "aWQ8zzi1EAQ",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731407400000,
- "slot_end": 1731409200000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/10GOrQfQ0ldlyvKU05TvdHfQd4G2zNNTzfEe2i2bfgMQ",
- "resources_slides": null,
"speakers": [
- "task-ohmori",
- "yusuke-nakae"
- ]
+ "jordi-baylina"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731474000000,
+ "slot_end": 1731475800000,
+ "slot_roomId": "stage-2",
+ "resources_presentation": "https://docs.google.com/presentation/d/1p0VlUcR1aOi--jA4hFb8aBF8mAWBuf-2vwun38CXBtI"
},
"vector": [
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -890389,6 +888498,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -890832,18 +888942,6 @@
0,
0,
0,
- 6,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -890861,6 +888959,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -890910,7 +889009,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -891196,274 +889294,19 @@
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
2,
0,
0,
0,
- 2,
0,
0,
0,
0,
- 2,
0,
0,
0,
0,
0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0
- ]
- },
- {
- "session": {
- "id": "zkpassport-private-unforgeable-identity",
- "sourceId": "K3GWST",
- "title": "ZKpassport: Private Unforgeable Identity",
- "description": "This talk presents ZKpassport, an identity verification solution integrating zero-knowledge proofs with ePassports to achieve privacy-preserving and unforgeable government-attested digital identities. We will delve into the technical architecture, implementation challenges, and practical applications. Attendees will gain insights into the development process, benefits, and potential uses of this technology in enhancing digital identity privacy and security.",
- "track": "Applied Cryptography",
- "type": "Talk",
- "expertise": "Intermediate",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "tags": [
- "Privacy",
- "Identity",
- "Zero-Knowledge",
- "noir",
- "Identity",
- "Privacy",
- "Zero-Knowledge"
- ],
- "keywords": [
- "ZK",
- "NFC",
- "Noir",
- "PLONK"
- ],
- "duration": 1189,
- "language": "en",
- "sources_swarmHash": "8ff112bba1682d13788042e5ab586ab285935e607ec2031734b6ed5acbad29ea",
- "sources_youtubeId": "W6C-duDEiOU",
- "sources_ipfsHash": "",
- "sources_livepeerId": "",
- "sources_streamethId": null,
- "transcript_vtt": "No VTT link provided",
- "transcript_text": "No transcript text provided",
- "eventId": "devcon-7",
- "slot_start": 1731484200000,
- "slot_end": 1731486000000,
- "slot_roomId": "classroom-a",
- "resources_presentation": "https://docs.google.com/presentation/d/1oOW6cu6Z74Nvx5lSpva4kFP8hggWPnZdL6MvVt9Hc9U",
- "resources_slides": null,
- "speakers": [
- "michael-elliot",
- "theo-madzou"
- ]
- },
- "vector": [
0,
0,
0,
@@ -891474,11 +889317,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -891634,12 +889472,6 @@
0,
0,
0,
- 6,
- 0,
- 0,
- 6,
- 0,
- 0,
0,
0,
0,
@@ -891673,9 +889505,14 @@
0,
0,
0,
+ 2,
+ 2,
+ 2,
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -891688,10 +889525,47 @@
0,
0,
0,
+ 0
+ ]
+ },
+ {
+ "session": {
+ "id": "zoom-in-on-eof-stack-validation",
+ "sourceId": "YYGYGF",
+ "title": "Zoom in on EOF stack validation",
+ "description": "Deep dive into EIP-5450: EOF stack validation spec and explaining some of the rationale behind it.",
+ "track": "Core Protocol",
+ "type": "Talk",
+ "expertise": "Expert",
+ "audience": "Engineering",
+ "featured": false,
+ "doNotRecord": false,
+ "keywords": [
+ "EVM",
+ "EOF"
+ ],
+ "tags": [
+ "Core Protocol",
+ "eof",
+ "Core",
+ "Protocol"
+ ],
+ "language": "en",
+ "speakers": [
+ "andrei-maiboroda"
+ ],
+ "eventId": "devcon-7",
+ "slot_start": 1731555000000,
+ "slot_end": 1731556800000,
+ "slot_roomId": "stage-3",
+ "resources_presentation": "https://docs.google.com/presentation/d/1d8txUWtGhcQzZvxbPw_N_fi_3997eaZr5RJ2nDVrHkg"
+ },
+ "vector": [
0,
0,
0,
0,
+ 6,
0,
0,
0,
@@ -892228,7 +890102,6 @@
0,
0,
0,
- 6,
0,
0,
0,
@@ -892265,7 +890138,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -892315,7 +890187,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -892332,7 +890203,6 @@
0,
0,
0,
- 2,
0,
0,
0,
@@ -892439,6 +890309,7 @@
0,
0,
0,
+ 6,
0,
0,
0,
@@ -892458,6 +890329,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -892730,6 +890602,7 @@
0,
0,
0,
+ 2,
0,
0,
0,
@@ -892741,6 +890614,8 @@
0,
0,
0,
+ 2,
+ 2,
0,
0,
0,
@@ -892777,2525 +890652,6 @@
0,
0,
0,
- 2,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0
- ]
- },
- {
- "session": {
- "id": "zkproving-the-history-of-ethereum-in-real-time",
- "sourceId": "TVNJ99",
- "title": "zkProving the history of Ethereum in real time.",
- "description": "I'll explain the current work that we are doing in the Polygon zk teams to improve the performance of the provers and the quality of the tooling.\r\nI'll will explain how we can parallelise the generation of the proof and how we can integrate with different hardware and software so that it should allow to build a zk proof of a block in real time. \r\nI'll explain also how this proofs can be recursively linked to build a zkProof that can proof the whole Ethereum history from the genesis.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Expert",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "Lightclient",
- "type1",
- "STARK"
- ],
- "tags": [
- "ZK-EVMs",
- "ZKP",
- "Zero-Knowledge",
- "lightclient",
- "type1",
- "starks",
- "Zero-Knowledge",
- "ZK-EVMs",
- "ZKP"
- ],
- "language": "en",
- "speakers": [
- "jordi-baylina"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731474000000,
- "slot_end": 1731475800000,
- "slot_roomId": "stage-2",
- "resources_presentation": "https://docs.google.com/presentation/d/1p0VlUcR1aOi--jA4hFb8aBF8mAWBuf-2vwun38CXBtI"
- },
- "vector": [
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 2,
- 2,
- 0,
- 0,
- 0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0
- ]
- },
- {
- "session": {
- "id": "zoom-in-on-eof-stack-validation",
- "sourceId": "YYGYGF",
- "title": "Zoom in on EOF stack validation",
- "description": "Deep dive into EIP-5450: EOF stack validation spec and explaining some of the rationale behind it.",
- "track": "Core Protocol",
- "type": "Talk",
- "expertise": "Expert",
- "audience": "Engineering",
- "featured": false,
- "doNotRecord": false,
- "keywords": [
- "EVM",
- "EOF"
- ],
- "tags": [
- "Core Protocol",
- "eof",
- "Core",
- "Protocol"
- ],
- "language": "en",
- "speakers": [
- "andrei-maiboroda"
- ],
- "eventId": "devcon-7",
- "slot_start": 1731555000000,
- "slot_end": 1731556800000,
- "slot_roomId": "stage-3",
- "resources_presentation": "https://docs.google.com/presentation/d/1d8txUWtGhcQzZvxbPw_N_fi_3997eaZr5RJ2nDVrHkg"
- },
- "vector": [
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 6,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 2,
- 2,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
- 0,
0,
0,
0,
@@ -895686,7 +891042,6 @@
0,
0,
0,
- 0,
6,
0,
0,
@@ -896872,8 +892227,6 @@
0,
0,
0,
- 0,
- 0,
2,
0,
0,
diff --git a/devcon-api/data/vectors/dictionary.json b/devcon-api/data/vectors/dictionary.json
index 1bcce964..6a3d0d9f 100644
--- a/devcon-api/data/vectors/dictionary.json
+++ b/devcon-api/data/vectors/dictionary.json
@@ -84,7 +84,6 @@
"guo-liu",
"rumee-singh",
"arun-maharajan",
- "thakur-dhakal",
"david-casey",
"rebecca-kacherginsky",
"sean-anderson",
@@ -127,8 +126,8 @@
"bianca-buzea",
"oren-katz",
"farhad-asgarov",
- "lukas-rosario",
"conner-swenberg",
+ "lukas-rosario",
"rob-knight",
"veronica-zheng",
"forest-fang",
@@ -200,7 +199,6 @@
"christoph-schlegel",
"dr-john-fletcher-phd",
"kilian-hikaru-scheutwinkel",
- "robert-drost",
"elia-anzuoni",
"jarrad-hope",
"nalin-b",
@@ -211,8 +209,10 @@
"simona-pop",
"songyi-lee",
"sebastian-buergel",
+ "robin-hanson",
"eli-dourado",
"isla-munro",
+ "una-wang",
"gabriel-shapiro",
"lefteris-karapetsas",
"jerome-de-tychey",
@@ -233,9 +233,9 @@
"anna-stone",
"damaris-njoroge",
"andreas-tsamados",
- "julien",
"grant-southey",
"gregskrileth",
+ "julien",
"thomas-clowes",
"mikhail-kalinin",
"alex-vlasov",
@@ -264,7 +264,6 @@
"launamu",
"sejal-rekhan",
"kaseth",
- "robin-hanson",
"nathan-sexer",
"arnaucube",
"vivek-bhupatiraju",
@@ -309,9 +308,9 @@
"oxytocin",
"mario-havel",
"josh-davis",
- "eniko-nagy",
"echo",
"eitan",
+ "eniko-nagy",
"siddharth-vaderaa",
"mark-holt",
"philip-daian",
@@ -461,9 +460,6 @@
"dennison-bertram",
"chih-cheng-liang",
"marc-nitzsche",
- "arthur-roing-baer",
- "alex-declino",
- "rasmus-svensson",
"oliver-jl-renwick",
"laurel",
"yabir-garcia-benchakhtir",
@@ -498,8 +494,6 @@
"niamh",
"juan-benet",
"milan-cvitkovic",
- "gregthegreek",
- "cindy",
"anna-george",
"mteam",
"liam-eagen",
@@ -507,6 +501,7 @@
"david-furlong",
"emad-mostaque",
"veronica",
+ "robert-drost",
"pablo-sabbatella",
"carl-cervone",
"ignasi-ramos",
@@ -637,6 +632,7 @@
"joshua-tan",
"gabriel-coutinho-de-paula",
"augusto-teixeira",
+ "gregthegreek",
"mikko-ohtamaa",
"vanishree-rao",
"alex-towle",
@@ -657,8 +653,8 @@
"tracheopteryx",
"hadrien-croubois",
"sophia-spirlock",
- "chirag-mahaveer-parmar",
"hopinheimer",
+ "chirag-mahaveer-parmar",
"julio-cesar-arango",
"stephane-tetsing",
"alex-gluchowski",
@@ -703,6 +699,7 @@
"nebojsa-urosevic",
"pavle-drobnjak",
"jacek-glen",
+ "cindy",
"alexey-shekhirin",
"hiroyuki-tachibana",
"nico",
@@ -983,7 +980,6 @@
"proof",
"optimised",
"work",
- "fork",
"Gas",
"compilers",
"Civil Resistance",
@@ -1182,14 +1178,12 @@
"inspiration",
"Conviction",
"liability",
- "ux",
- "wallet",
- "Key Management",
"lvr",
"mycofi",
"Paymaster",
"creators",
"frames",
+ "fork",
"dprk",
"l2",
"service",
@@ -1273,6 +1267,7 @@
"democracy",
"philosophy",
"sumcheck",
+ "wallet",
"succinct",
"stateless",
"permissions",
@@ -1293,6 +1288,8 @@
"real-time",
"unified",
"ens",
+ "ux",
+ "Key Management",
"plugin",
"vadcops",
"correct-by-construction",