diff --git a/devcon-api/data/events/devcon-7.json b/devcon-api/data/events/devcon-7.json index 12e28e34..a9510d14 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": "1731555403257" + "version": "1731556835253" } \ No newline at end of file diff --git a/devcon-api/data/speakers/vitalik-buterin.json b/devcon-api/data/speakers/vitalik-buterin.json index d67f1ccd..dbe61699 100644 --- a/devcon-api/data/speakers/vitalik-buterin.json +++ b/devcon-api/data/speakers/vitalik-buterin.json @@ -1,8 +1,8 @@ { "id": "vitalik-buterin", - "sourceId": "ADDJPN", + "sourceId": "FLKFV8", "name": "Vitalik Buterin", - "avatar": "", + "avatar": "https://speak.devcon.org/media/avatars/Vitalik_Headshot_1_kWIW5OC.jpeg", "description": "", - "hash": "cdf98dc87493f9be525bb22330d18831cec05fee74f83b299db1335032df98a2" -} \ No newline at end of file + "hash": "abe61f2ea25d0de38a6912bdbc284f2f17060c64c9f3913a7024106da55bf707" +} diff --git a/devcon-api/data/vectors/devcon-7.json b/devcon-api/data/vectors/devcon-7.json index 47dd2800..3aa889a1 100644 --- a/devcon-api/data/vectors/devcon-7.json +++ b/devcon-api/data/vectors/devcon-7.json @@ -102645,8 +102645,8 @@ "resources_presentation": "https://docs.google.com/presentation/d/1IMXFflR1DsQZPhVlnc9Ss-Xp6JJcahFgzp1FXWS8ldw", "resources_slides": null, "speakers": [ - "conner-swenberg", - "lukas-rosario" + "lukas-rosario", + "conner-swenberg" ] }, "vector": [ @@ -207862,9 +207862,9 @@ "resources_presentation": "https://docs.google.com/presentation/d/1W0jwOLdutdtpuJNo6WvxKfcV8v0h4mUvf0CLm68DfjQ", "resources_slides": null, "speakers": [ + "julien", "grant-southey", "gregskrileth", - "julien", "thomas-clowes" ] }, @@ -229711,11 +229711,11 @@ }, { "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": "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", @@ -229724,17 +229724,12 @@ "keywords": [], "tags": [], "language": "en", - "speakers": [ - "skylar-weaver", - "nathan-sexer" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731385800000, - "slot_end": 1731388500000, + "slot_start": 1731653700000, + "slot_end": 1731655200000, "slot_roomId": "main-stage", - "sources_youtubeId": "c8suX-_PTo8", - "sources_swarmHash": "6579559384c3752ff4c849eff1d48dbe1dfc815f78de54dc6debbd2a36b5e991", - "resources_presentation": "https://docs.google.com/presentation/d/1Qo0Nhlnmak6ecCzF_nhTStunc63frayP5RYA5bLD3TQ" + "resources_presentation": "https://docs.google.com/presentation/d/1kqglc9q5GnXKZpzbgqVtlSzsWyTWh7CppeW0EvBT9mc" }, "vector": [ 0, @@ -229743,10 +229738,12 @@ 0, 0, 0, - 6, 0, 0, 0, + 6, + 0, + 0, 0, 0, 0, @@ -229916,7 +229913,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -229999,7 +229995,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -231069,40 +231064,30 @@ }, { "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.", - "track": "Applied Cryptography", + "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", + "expertise": "", "audience": "Engineering", "featured": false, "doNotRecord": false, - "keywords": [ - "Folding schemes", - "IVC", - "Nova" - ], - "tags": [ - "Libraries", - "Zero-Knowledge", - "Cryptography", - "nova", - "Cryptography", - "Libraries", - "Zero-Knowledge" - ], + "keywords": [], + "tags": [], "language": "en", "speakers": [ - "pierre-daix-moreux", - "arnaucube" + "skylar-weaver", + "nathan-sexer" ], "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": 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, @@ -231111,12 +231096,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -231154,7 +231138,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -231286,6 +231269,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -231865,9 +231849,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -232122,7 +232103,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -232415,10 +232395,15 @@ 0, 0, 0, - 2, 0, 0, 0, + 0, + 0, + 0, + 2, + 0, + 0, 2, 0, 0, @@ -232437,40 +232422,40 @@ }, { "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!", + "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": "Intermediate", - "audience": "Research", + "audience": "Engineering", "featured": false, "doNotRecord": false, + "keywords": [ + "Folding schemes", + "IVC", + "Nova" + ], "tags": [ - "MPC", - "Privacy", - "Use cases of cryptography" + "Libraries", + "Zero-Knowledge", + "Cryptography", + "nova", + "Cryptography", + "Libraries", + "Zero-Knowledge" ], - "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" - ] + "pierre-daix-moreux", + "arnaucube" + ], + "eventId": "devcon-7", + "slot_start": 1731472200000, + "slot_end": 1731474000000, + "slot_roomId": "stage-3", + "resources_presentation": "https://docs.google.com/presentation/d/1IOfjp_pKz83JTceKqk5Rve7U1YRQJSc4MA5OPmnj6oE" }, "vector": [ 0, @@ -232522,8 +232507,7 @@ 0, 0, 0, - 0, - 0, + 6, 0, 0, 0, @@ -233234,6 +233218,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -233250,7 +233237,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -233311,7 +233297,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -233338,7 +233323,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -233491,6 +233475,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -233787,7 +233772,6 @@ 0, 0, 0, - 0, 2, 0, 0, @@ -233800,51 +233784,51 @@ 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", + "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": "Developper", + "audience": "Research", "featured": false, "doNotRecord": false, - "keywords": [ - "Holistic monitoring", - "Architecture research" - ], "tags": [ - "Architecture", - "Tooling", - "DevEx", - "Event monitoring", - "research", - "DevEx", - "Event monitoring", - "Tooling" + "MPC", + "Privacy", + "Use cases of cryptography" ], + "keywords": [], + "duration": 1517, "language": "en", - "speakers": [ - "mateusz-radomski" - ], + "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": 1731638700000, - "slot_end": 1731645900000, - "slot_roomId": "classroom-c", - "resources_presentation": "https://docs.google.com/presentation/d/1T24SoFUkubwO-ppCiYWJoisNwayKtozmAgEJYNPvVho" + "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, 0, 0, - 6, - 0, 0, 0, 0, @@ -233852,6 +233836,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -234610,7 +234595,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -234651,7 +234635,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -234681,6 +234664,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -234707,6 +234691,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -234840,7 +234828,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -234858,7 +234845,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -235155,6 +235141,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -235162,7 +235149,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -235172,38 +235158,45 @@ }, { "session": { - "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", + "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", "featured": false, "doNotRecord": false, - "keywords": [], - "tags": [], + "keywords": [ + "Holistic monitoring", + "Architecture research" + ], + "tags": [ + "Architecture", + "Tooling", + "DevEx", + "Event monitoring", + "research", + "DevEx", + "Event monitoring", + "Tooling" + ], "language": "en", - "speakers": [], + "speakers": [ + "mateusz-radomski" + ], "eventId": "devcon-7", - "slot_start": 1731668400000, - "slot_end": 1731675600000, - "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1TSMgbtSJLOzOAEiyPEoXuekpCOjQiJ2mYcLOPgFaF3E" + "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, - 6, - 0, + 6, 0, 0, 0, @@ -235465,6 +235458,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -235969,6 +235963,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -235977,6 +235972,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -236008,6 +236004,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -236196,6 +236193,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -236213,6 +236211,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -236507,7 +236506,6 @@ 2, 0, 0, - 2, 0, 0, 0, @@ -236517,6 +236515,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -236525,9 +236525,9 @@ }, { "session": { - "id": "dj-anderson", - "sourceId": "V393ZX", - "title": "DJ Anderson", + "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", @@ -236540,10 +236540,10 @@ "language": "en", "speakers": [], "eventId": "devcon-7", - "slot_start": 1731567600000, - "slot_end": 1731571200000, + "slot_start": 1731668400000, + "slot_end": 1731675600000, "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/11UdQ5iBzKBx_FS4T0nj0XPX9C1X0bSm-aP2bwq7jrOI" + "resources_presentation": "https://docs.google.com/presentation/d/1TSMgbtSJLOzOAEiyPEoXuekpCOjQiJ2mYcLOPgFaF3E" }, "vector": [ 0, @@ -237878,9 +237878,9 @@ }, { "session": { - "id": "dj-i34r7h", - "sourceId": "QTHGFE", - "title": "DJ @i34r7h", + "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", @@ -237893,10 +237893,10 @@ "language": "en", "speakers": [], "eventId": "devcon-7", - "slot_start": 1731639600000, - "slot_end": 1731643200000, + "slot_start": 1731567600000, + "slot_end": 1731571200000, "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1f64FrhWEvOeHjw8XlNFarHOwwNkBaofQKZdOavm-Zq4" + "resources_presentation": "https://docs.google.com/presentation/d/11UdQ5iBzKBx_FS4T0nj0XPX9C1X0bSm-aP2bwq7jrOI" }, "vector": [ 0, @@ -239231,9 +239231,9 @@ }, { "session": { - "id": "dj-mayu", - "sourceId": "XV779L", - "title": "DJ MAYU", + "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", @@ -239246,10 +239246,10 @@ "language": "en", "speakers": [], "eventId": "devcon-7", - "slot_start": 1731646800000, - "slot_end": 1731650400000, + "slot_start": 1731639600000, + "slot_end": 1731643200000, "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1t2zQdmj0AJUDWbkdwI8GyR90vs3nQ_7TKvydOwUZYYk" + "resources_presentation": "https://docs.google.com/presentation/d/1f64FrhWEvOeHjw8XlNFarHOwwNkBaofQKZdOavm-Zq4" }, "vector": [ 0, @@ -240584,27 +240584,25 @@ }, { "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.", + "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", - "expertise": "Intermediate", - "audience": "Community", + "expertise": "", + "audience": "Engineering", "featured": false, "doNotRecord": false, "keywords": [], "tags": [], "language": "en", - "speakers": [ - "pino7" - ], + "speakers": [], "eventId": "devcon-7", - "slot_start": 1731564000000, - "slot_end": 1731567600000, + "slot_start": 1731646800000, + "slot_end": 1731650400000, "slot_roomId": "music-stage", - "resources_presentation": "https://docs.google.com/presentation/d/1FZiG2A1-zzZBVPF6IvnlZPydiJX9JFyp4ngPzFzJTEo" + "resources_presentation": "https://docs.google.com/presentation/d/1t2zQdmj0AJUDWbkdwI8GyR90vs3nQ_7TKvydOwUZYYk" }, "vector": [ 0, @@ -240873,7 +240871,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -241917,16 +241914,17 @@ 0, 0, 0, - 2, 0, 0, + 2, + 0, 0, + 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -241939,54 +241937,27 @@ }, { "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": "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", "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" - ], - "duration": 3425, + "keywords": [], + "tags": [], "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": 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" - ] + "pino7" + ], + "eventId": "devcon-7", + "slot_start": 1731564000000, + "slot_end": 1731567600000, + "slot_roomId": "music-stage", + "resources_presentation": "https://docs.google.com/presentation/d/1FZiG2A1-zzZBVPF6IvnlZPydiJX9JFyp4ngPzFzJTEo" }, "vector": [ 0, @@ -241997,6 +241968,7 @@ 0, 0, 0, + 0, 6, 0, 0, @@ -242254,12 +242226,10 @@ 0, 0, 0, + 6, + 0, 0, 0, - 6, - 6, - 6, - 6, 0, 0, 0, @@ -242754,7 +242724,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -242796,8 +242765,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -242825,7 +242792,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -243008,8 +242974,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -243301,7 +243265,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -243316,41 +243279,75 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0 ] }, { "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", - "expertise": "Intermediate", - "audience": "Engineering", + "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": [ - "Intents", - "MEV", - "PBS", - "Redistribution" - ], "tags": [ - "redistribution" + "Product-market fit", + "User Experience", + "UI/UX", + "User Research", + "product", + "discovery", + "Product-market fit", + "UI/UX", + "User Experience", + "User Research" ], - "language": "en", - "speakers": [ - "felix-leupold" + "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": 1731639900000, - "slot_end": 1731640500000, + "slot_start": 1731394800000, + "slot_end": 1731398400000, "slot_roomId": "stage-2", - "resources_presentation": "https://docs.google.com/presentation/d/1y6tAISW_K9exOHiT-8JDt3qSFgyDYP0v5Zkc3T7JIdw" + "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, + 0, + 0, + 0, + 0, + 0, 0, 0, 6, @@ -243612,6 +243609,17 @@ 0, 0, 0, + 6, + 6, + 6, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -243622,7 +243630,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -244100,6 +244107,14 @@ 0, 0, 0, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -244134,6 +244149,10 @@ 0, 0, 0, + 2, + 2, + 0, + 0, 0, 0, 0, @@ -244159,6 +244178,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -244340,6 +244361,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -244372,36 +244395,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, @@ -244665,11 +244658,9 @@ 0, 0, 0, - 2, - 0, - 0, 0, 0, + 2, 0, 0, 0, @@ -244683,40 +244674,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.", - "track": "Security", - "type": "Workshop", + "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": "Developer", + "audience": "Engineering", "featured": false, - "doNotRecord": true, + "doNotRecord": false, "keywords": [ - "user safety", - "developer safety", - "phishing" + "Intents", + "MEV", + "PBS", + "Redistribution" ], "tags": [ - "Tooling", - "Security", - "phishing", - "Security", - "Tooling" + "redistribution" ], "language": "en", "speakers": [ - "tincho", - "matta-the-red-guild" + "felix-leupold" ], "eventId": "devcon-7", - "slot_start": 1731488400000, - "slot_end": 1731495600000, - "slot_roomId": "classroom-b", - "resources_presentation": "https://docs.google.com/presentation/d/1iQKRk0GBHlEdWgzH2yQxE2MJqGiiPO9fQI4PkTbLKOk" + "slot_start": 1731639900000, + "slot_end": 1731640500000, + "slot_roomId": "stage-2", + "resources_presentation": "https://docs.google.com/presentation/d/1y6tAISW_K9exOHiT-8JDt3qSFgyDYP0v5Zkc3T7JIdw" }, "vector": [ + 0, + 0, 6, 0, 0, @@ -244986,11 +244975,10 @@ 0, 0, 0, + 6, 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -245466,7 +245454,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -245487,7 +245474,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -246027,13 +246013,14 @@ 0, 0, 0, + 0, 2, 0, 0, 0, + 2, 0, 0, - 2, 0, 0, 0, @@ -246049,38 +246036,38 @@ }, { "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.", + "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": "Lightning Talk", + "type": "Workshop", "expertise": "Intermediate", - "audience": "Research", + "audience": "Developer", "featured": false, - "doNotRecord": false, + "doNotRecord": true, "keywords": [ - "Contest" + "user safety", + "developer safety", + "phishing" ], "tags": [ + "Tooling", "Security", - "Bug", - "Bounties", - "contest", - "Architecture", - "Auditing", - "Bug", - "Security" + "phishing", + "Security", + "Tooling" ], "language": "en", "speakers": [ - "jota-carpanelli" + "tincho", + "matta-the-red-guild" ], "eventId": "devcon-7", - "slot_start": 1731657000000, - "slot_end": 1731657600000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1nsS3htMgQANlE-F_Bcm9jAbdeixMwbjLd0u9GrwuCV0" + "slot_start": 1731488400000, + "slot_end": 1731495600000, + "slot_roomId": "classroom-b", + "resources_presentation": "https://docs.google.com/presentation/d/1iQKRk0GBHlEdWgzH2yQxE2MJqGiiPO9fQI4PkTbLKOk" }, "vector": [ 6, @@ -246355,9 +246342,9 @@ 0, 0, 0, - 0, - 0, 6, + 6, + 0, 0, 0, 0, @@ -246853,6 +246840,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -246894,7 +246883,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -246984,7 +246972,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -247089,7 +247076,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -247107,7 +247093,8 @@ 0, 0, 2, - 2, + 0, + 0, 0, 0, 0, @@ -247398,8 +247385,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -247415,47 +247402,47 @@ }, { "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.", - "track": "Real World Ethereum", + "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": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", + "expertise": "Intermediate", + "audience": "Research", "featured": false, "doNotRecord": false, "keywords": [ - "mainstream" + "Contest" ], "tags": [ - "Quadratic Voting", - "Public good", - "Local Impact", - "UI/UX", - "mainstream", - "Public good", - "UI/UX" + "Security", + "Bug", + "Bounties", + "contest", + "Architecture", + "Auditing", + "Bug", + "Security" ], "language": "en", "speakers": [ - "kevin-owocki" + "jota-carpanelli" ], "eventId": "devcon-7", - "slot_start": 1731581400000, - "slot_end": 1731582000000, + "slot_start": 1731657000000, + "slot_end": 1731657600000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1Lf82ct08SpegO30t849kscAqeyNa8bTNVpMQ8ljElfA" + "resources_presentation": "https://docs.google.com/presentation/d/1nsS3htMgQANlE-F_Bcm9jAbdeixMwbjLd0u9GrwuCV0" }, "vector": [ + 6, 0, 0, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -248198,6 +248185,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -248256,11 +248244,10 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, + 2, 0, 0, 0, @@ -248306,7 +248293,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -248351,6 +248337,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -248406,7 +248393,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -248439,7 +248425,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -248457,6 +248442,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -248474,7 +248460,7 @@ 0, 0, 2, - 0, + 2, 0, 0, 0, @@ -248765,9 +248751,11 @@ 0, 0, 0, + 2, + 0, + 0, 0, 0, - 2, 0, 0, 0, @@ -248780,39 +248768,37 @@ }, { "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.", + "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": "Beginner", - "audience": "Product", + "audience": "Community", "featured": false, "doNotRecord": false, "keywords": [ - "digital-product-passports", - "DPPs", - "luxury" + "mainstream" ], "tags": [ - "Digital Sovereignty", - "Use Cases", - "Regulation", - "luxury", - "Digital Sovereignty", - "Regulation", - "Use Cases" + "Quadratic Voting", + "Public good", + "Local Impact", + "UI/UX", + "mainstream", + "Public good", + "UI/UX" ], "language": "en", "speakers": [ - "james-morgan" + "kevin-owocki" ], "eventId": "devcon-7", - "slot_start": 1731567600000, - "slot_end": 1731568200000, + "slot_start": 1731581400000, + "slot_end": 1731582000000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1oolmmoeS_8L3O435iq2vuXQPr9H_eWlvs-2T3XokFwU" + "resources_presentation": "https://docs.google.com/presentation/d/1Lf82ct08SpegO30t849kscAqeyNa8bTNVpMQ8ljElfA" }, "vector": [ 0, @@ -249090,7 +249076,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -249614,7 +249599,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -249625,6 +249609,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -249643,7 +249632,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -249771,6 +249759,18 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -249792,6 +249792,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -249822,6 +249826,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -249841,28 +249849,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, @@ -250133,8 +250119,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -250147,50 +250133,39 @@ }, { "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": "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": "Business", + "audience": "Product", "featured": false, "doNotRecord": false, - "tags": [ - "Layer 2s", - "DevRel", - "Best Practices", - "management", - "stakeholder", - "Best Practices", - "DevRel", - "Layer 2s" - ], "keywords": [ - "Ecosystem Building", - "Ecosystem Design", - "Developer Experience", - "Stakeholder Management" + "digital-product-passports", + "DPPs", + "luxury" + ], + "tags": [ + "Digital Sovereignty", + "Use Cases", + "Regulation", + "luxury", + "Digital Sovereignty", + "Regulation", + "Use Cases" ], - "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", + "speakers": [ + "james-morgan" + ], "eventId": "devcon-7", - "slot_start": 1731402000000, - "slot_end": 1731402600000, + "slot_start": 1731567600000, + "slot_end": 1731568200000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/12auC9dhscSkSUtYU1CqtRqHz64-ljDXc1f7otM8hLMw", - "resources_slides": null, - "speakers": [ - "nine-arnakorn" - ] + "resources_presentation": "https://docs.google.com/presentation/d/1oolmmoeS_8L3O435iq2vuXQPr9H_eWlvs-2T3XokFwU" }, "vector": [ 0, @@ -250199,7 +250174,6 @@ 0, 0, 0, - 0, 6, 0, 0, @@ -250973,7 +250947,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -250994,6 +250967,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -251008,7 +250982,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -251023,6 +250996,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -251050,6 +251024,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -251116,7 +251091,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -251221,7 +251195,8 @@ 0, 0, 2, - 2, + 0, + 0, 0, 0, 0, @@ -251510,8 +251485,8 @@ 0, 0, 0, - 2, 0, + 2, 0, 0, 0, @@ -251525,47 +251500,49 @@ }, { "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", + "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": "Business", "featured": false, "doNotRecord": false, "tags": [ - "Coordination", - "Vision", - "Use Cases", - "institutional", - "Coordination", - "Use Cases", - "Vision" + "Layer 2s", + "DevRel", + "Best Practices", + "management", + "stakeholder", + "Best Practices", + "DevRel", + "Layer 2s" ], "keywords": [ - "Business", - "Enterprise", - "Instituional" + "Ecosystem Building", + "Ecosystem Design", + "Developer Experience", + "Stakeholder Management" ], - "duration": 602, + "duration": 407, "language": "en", - "sources_swarmHash": "627a8020ea8fffe7e60da9ea41e68e2239bf60b5384058c21bd9da1f40eec92e", - "sources_youtubeId": "dYgucH3a7sI", + "sources_swarmHash": "3ca335e97a65bd21e260157bab87ec0fc8fb8c50e77214212c844d794eb17896", + "sources_youtubeId": "xqs8trszoOY", "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/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": 1731480000000, - "slot_end": 1731480600000, + "slot_start": 1731402000000, + "slot_end": 1731402600000, "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/1f1uiHRqQIfhY0F3DmSPJ-wpu3lCdP00YCID-a2-UblQ", + "resources_presentation": "https://docs.google.com/presentation/d/12auC9dhscSkSUtYU1CqtRqHz64-ljDXc1f7otM8hLMw", "resources_slides": null, "speakers": [ - "karen-scarbrough" + "nine-arnakorn" ] }, "vector": [ @@ -251575,9 +251552,8 @@ 0, 0, 0, - 6, - 0, 0, + 6, 0, 0, 0, @@ -252350,6 +252326,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -252384,6 +252361,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -252397,8 +252375,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -252473,7 +252449,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -252494,6 +252469,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -252551,7 +252527,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -252599,6 +252574,8 @@ 0, 0, 2, + 2, + 0, 0, 0, 0, @@ -252901,41 +252878,48 @@ }, { "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", + "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, - "keywords": [ - "Pairing", - "based", - "ZK" - ], "tags": [ - "ZKP", - "Cryptography", - "SNARK", - "zk", - "based", - "pairing", - "Cryptography", - "SNARK", - "ZKP" + "Coordination", + "Vision", + "Use Cases", + "institutional", + "Coordination", + "Use Cases", + "Vision" ], - "language": "en", - "speakers": [ - "ivo-kubjas" + "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": 1731474000000, - "slot_end": 1731475800000, - "slot_roomId": "stage-3", - "resources_presentation": "https://docs.google.com/presentation/d/1uBrjsIa4svOJ9BePcS4YgEcFXFjVxeeeS9RBVSKBwzw" + "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, @@ -252944,12 +252928,11 @@ 0, 0, 0, + 6, 0, 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -253700,7 +253683,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -253732,7 +253714,13 @@ 0, 0, 0, - 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -253838,6 +253826,23 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -253899,6 +253904,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -253942,6 +253951,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -253968,33 +253981,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, @@ -254252,10 +254238,8 @@ 0, 0, 0, - 2, - 0, - 0, 0, + 2, 0, 0, 0, @@ -254270,58 +254254,54 @@ }, { "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", + "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": "Stakers/Validators", + "audience": "Engineering", "featured": false, "doNotRecord": false, - "tags": [ - "Core Protocol", - "Staking", - "Pectra", - "Core Protocol", - "Staking" - ], "keywords": [ - "Pectra" + "Pairing", + "based", + "ZK" + ], + "tags": [ + "ZKP", + "Cryptography", + "SNARK", + "zk", + "based", + "pairing", + "Cryptography", + "SNARK", + "ZKP" ], - "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" - ] + "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, 0, - 6, - 0, 0, 0, 0, 0, 0, 0, + 6, 0, 0, 0, @@ -255073,14 +255053,12 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, - 2, - 0, - 0, 0, 0, 0, @@ -255107,6 +255085,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -255136,6 +255115,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -255188,8 +255168,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -255344,6 +255322,9 @@ 0, 0, 2, + 2, + 2, + 0, 0, 0, 0, @@ -255624,13 +255605,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -255642,43 +255623,43 @@ }, { "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.", + "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": "Expert", - "audience": "Engineering", + "expertise": "Intermediate", + "audience": "Stakers/Validators", "featured": false, "doNotRecord": false, "tags": [ "Core Protocol", - "Account Abstraction", - "eip", - "Account Abstraction", - "Core Protocol" + "Staking", + "Pectra", + "Core Protocol", + "Staking" ], "keywords": [ - "EIP" + "Pectra" ], - "duration": 1299, + "duration": 1218, "language": "en", - "sources_swarmHash": "d4c1051f49830760c82a47ec5d0413b0d5fef571e4c09d5a7a0c76f69753c619", - "sources_youtubeId": "_k5fKlKBWV4", + "sources_swarmHash": "7232962eceb9c9b07027a3ebb1759835c57a4c1aacf89e245dbceaca4a6ae4dc", + "sources_youtubeId": "EwW6dNi9VCY", "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/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": 1731393000000, - "slot_end": 1731394800000, + "slot_start": 1731394800000, + "slot_end": 1731396600000, "slot_roomId": "stage-1", - "resources_presentation": "https://docs.google.com/presentation/d/15huammnvrT8ljoiAi9Bnn4jcV_r6L0sm3_gBK-LqQ-4", + "resources_presentation": "https://docs.google.com/presentation/d/1Q5srMGhMm8grwI_O0CFKN_QN1QRx24-AxIwgbDha6U0", "resources_slides": null, "speakers": [ - "lightclient" + "paul-harris" ] }, "vector": [ @@ -255845,7 +255826,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -255963,6 +255943,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -256482,8 +256463,6 @@ 0, 0, 0, - 2, - 0, 0, 0, 0, @@ -256562,6 +256541,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -256993,16 +256973,17 @@ 0, 0, 0, + 2, + 0, 0, 0, - 2, - 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -257014,58 +256995,46 @@ }, { "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", + "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": "Intermediate", + "expertise": "Expert", "audience": "Engineering", "featured": false, "doNotRecord": false, "tags": [ - "Censorship Resistance", - "Consensus", "Core Protocol", - "PBS" + "Account Abstraction", + "eip", + "Account Abstraction", + "Core Protocol" ], "keywords": [ - "ePBS", - "EIP-7732" + "EIP" ], - "duration": 751, + "duration": 1299, "language": "en", - "sources_swarmHash": "e326ff4a5c85f7cfdcbb4ccebbd229632df88de258c3b4daa59aac0bad48ad30", - "sources_youtubeId": "P2DkizLb79w", + "sources_swarmHash": "d4c1051f49830760c82a47ec5d0413b0d5fef571e4c09d5a7a0c76f69753c619", + "sources_youtubeId": "_k5fKlKBWV4", "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", + "transcript_vtt": "No VTT link provided", + "transcript_text": "No transcript text provided", "eventId": "devcon-7", - "slot_start": 1731477600000, - "slot_end": 1731478500000, - "slot_roomId": "breakout-1", - "resources_presentation": "https://docs.google.com/presentation/d/1XP6W6A3-lCz0aeamZyGShkdG9rB-Lpip1Ceasz22olM", + "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": [ - "kira", - "caleb" + "lightclient" ] }, "vector": [ - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -257229,6 +257198,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -257336,14 +257306,6 @@ 0, 0, 0, - 6, - 6, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -257809,7 +257771,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -257823,7 +257784,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -257875,6 +257835,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -257952,65 +257913,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, @@ -258167,6 +258069,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -258365,11 +258268,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -258382,65 +258283,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, @@ -258502,6 +258348,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -258514,6 +258362,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, @@ -258529,6 +258423,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -258719,8 +258614,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -258796,6 +258689,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -259204,7 +259099,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -259268,6 +259162,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -259301,6 +259196,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -259340,7 +259236,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -259410,6 +259305,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -259470,10 +259366,6 @@ 0, 0, 0, - 2, - 2, - 2, - 2, 0, 0, 0, @@ -259746,7 +259638,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -259755,49 +259646,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 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, @@ -259807,15 +259660,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -259874,9 +259718,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -259889,10 +259735,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, @@ -260083,7 +259984,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -260172,6 +260072,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -260732,6 +260634,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -260790,6 +260693,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -260836,42 +260740,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, @@ -260955,6 +260823,10 @@ 0, 0, 0, + 2, + 2, + 2, + 2, 0, 0, 0, @@ -261110,70 +260982,18 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 0, - 0 - ] - }, - { - "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", - "featured": false, - "doNotRecord": false, - "tags": [ - "ZKP", - "Cryptography", - "SNARK", - "elliptic", - "curves", - "Cryptography", - "SNARK", - "ZKP" - ], - "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": 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, 0, 0, @@ -261184,7 +261004,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -261280,6 +261099,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -261288,6 +261108,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -261295,6 +261116,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, @@ -261304,6 +261160,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -261460,7 +261317,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -261580,6 +261436,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -261936,7 +261793,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -261998,7 +261854,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -262153,6 +262008,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -262204,7 +262060,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -262213,8 +262068,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -262336,6 +262189,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -262484,11 +262338,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -262501,32 +262353,6 @@ 0, 0, 0, - 0 - ] - }, - { - "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", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731468600000, - "slot_end": 1731471300000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/16hER2e4hzqPjZrObAFmLsPIfyEkBHspMF-2HfxORQAg" - }, - "vector": [ 0, 0, 0, @@ -262536,7 +262362,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -262638,12 +262463,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -262651,6 +262478,55 @@ 0, 0, 0, + 0 + ] + }, + { + "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", + "featured": false, + "doNotRecord": false, + "tags": [ + "ZKP", + "Cryptography", + "SNARK", + "elliptic", + "curves", + "Cryptography", + "SNARK", + "ZKP" + ], + "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": 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, 0, 0, @@ -262661,6 +262537,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -262936,6 +262813,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -263411,6 +263289,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -263472,6 +263351,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -263677,6 +263557,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -263685,6 +263566,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -263839,7 +263722,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -263848,55 +263730,15 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "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", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "EOF" - ], - "tags": [ - "Core Protocol", - "ACD", - "Testing", - "eof", - "ACD", - "Core Protocol", - "Testing" - ], - "language": "en", - "speakers": [ - "hubert-ritzdorf" - ], - "eventId": "devcon-7", - "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, - 6, 0, 0, 0, @@ -263995,9 +263837,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -264010,6 +263854,32 @@ 0, 0, 0, + 0 + ] + }, + { + "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", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731468600000, + "slot_end": 1731471300000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/16hER2e4hzqPjZrObAFmLsPIfyEkBHspMF-2HfxORQAg" + }, + "vector": [ 0, 0, 0, @@ -264019,6 +263889,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -264179,7 +264050,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -264660,7 +264530,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -264881,7 +264750,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -264927,13 +264795,11 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -265202,11 +265068,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -265219,51 +265083,8 @@ 0, 0, 0, - 0 - ] - }, - { - "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", - "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" - ], - "language": "en", - "speakers": [ - "elaine-hu" - ], - "eventId": "devcon-7", - "slot_start": 1731562200000, - "slot_end": 1731564000000, - "slot_roomId": "stage-5", - "resources_presentation": "https://docs.google.com/presentation/d/1Y6GrE_61ZfJ2Mxu9xrE-xcG7WBCWmKg3qYPa5F0zL3s" - }, - "vector": [ 0, 0, - 6, 0, 0, 0, @@ -265371,6 +265192,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -265379,15 +265201,55 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 0 + ] + }, + { + "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", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "EOF" + ], + "tags": [ + "Core Protocol", + "ACD", + "Testing", + "eof", + "ACD", + "Core Protocol", + "Testing" + ], + "language": "en", + "speakers": [ + "hubert-ritzdorf" + ], + "eventId": "devcon-7", + "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, + 6, 0, 0, 0, @@ -265549,7 +265411,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -265671,6 +265532,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -266012,7 +265874,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -266076,7 +265937,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -266093,7 +265953,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -266154,6 +266013,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -266210,7 +266070,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -266303,8 +266162,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -266377,6 +266234,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -266422,11 +266280,13 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -266571,12 +266431,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -266588,58 +266446,6 @@ 0, 0, 0, - 0 - ] - }, - { - "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", - "expertise": "Beginner", - "audience": "Stakers/Validators", - "featured": false, - "doNotRecord": false, - "tags": [ - "Staking", - "Best Practices", - "Accessibility", - "network", - "access", - "Accessibility", - "Best Practices", - "Staking" - ], - "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": 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, 0, @@ -266648,7 +266454,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -266750,9 +266555,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -266765,8 +266572,51 @@ 0, 0, 0, + 0 + ] + }, + { + "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", + "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" + ], + "language": "en", + "speakers": [ + "elaine-hu" + ], + "eventId": "devcon-7", + "slot_start": 1731562200000, + "slot_end": 1731564000000, + "slot_roomId": "stage-5", + "resources_presentation": "https://docs.google.com/presentation/d/1Y6GrE_61ZfJ2Mxu9xrE-xcG7WBCWmKg3qYPa5F0zL3s" + }, + "vector": [ 0, 0, + 6, 0, 0, 0, @@ -266929,9 +266779,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -267055,6 +266902,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -267420,7 +267268,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -267449,7 +267296,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -267477,7 +267323,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -267518,7 +267363,9 @@ 0, 0, 0, - 2, + 0, + 0, + 6, 0, 0, 0, @@ -267582,6 +267429,8 @@ 0, 0, 0, + 2, + 0, 0, 0, 0, @@ -267597,6 +267446,11 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -267684,7 +267538,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -267710,6 +267563,10 @@ 0, 0, 0, + 2, + 0, + 0, + 0, 0, 0, 0, @@ -267799,6 +267656,10 @@ 0, 0, 0, + 2, + 2, + 0, + 0, 0, 0, 0, @@ -267952,7 +267813,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -267960,52 +267820,12 @@ 0, 0, 0, - 2, 0, 0, 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", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Anti-Scam" - ], - "tags": [ - "Public good", - "SEA", - "Security" - ], - "language": "en", - "speakers": [ - "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, 0, 0, @@ -268104,10 +267924,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -268119,6 +267941,58 @@ 0, 0, 0, + 0 + ] + }, + { + "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", + "expertise": "Beginner", + "audience": "Stakers/Validators", + "featured": false, + "doNotRecord": false, + "tags": [ + "Staking", + "Best Practices", + "Accessibility", + "network", + "access", + "Accessibility", + "Best Practices", + "Staking" + ], + "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": 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, 0, @@ -268127,6 +268001,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -268293,7 +268168,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -268408,6 +268282,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -268750,7 +268627,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -268859,7 +268735,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -268898,6 +268773,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -268926,6 +268802,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -268953,6 +268830,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -269159,6 +269037,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -269313,66 +269192,6 @@ 0, 0, 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 2, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0 - ] - }, - { - "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.", - "track": "Core Protocol", - "type": "Lightning Talk", - "expertise": "Beginner", - "audience": "Stakers/Validators", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [ - "Decentralization", - "Home staking" - ], - "language": "en", - "speakers": [ - "diego-losada" - ], - "eventId": "devcon-7", - "slot_start": 1731643200000, - "slot_end": 1731643800000, - "slot_roomId": "stage-4", - "resources_presentation": "https://docs.google.com/presentation/d/149MDCwjImcWRfdIwZw6lfpbIkNtiT4AFD60ebK9hnNQ" - }, - "vector": [ - 0, - 0, - 0, - 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -269486,6 +269305,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -269493,13 +269313,49 @@ 0, 0, 0, + 2, 0, 0, 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", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Anti-Scam" + ], + "tags": [ + "Public good", + "SEA", + "Security" + ], + "language": "en", + "speakers": [ + "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, @@ -269652,7 +269508,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -269791,6 +269646,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -270194,7 +270050,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -270210,7 +270065,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -270249,6 +270103,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -270357,6 +270212,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -270490,6 +270346,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -270671,7 +270528,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -270679,64 +270535,16 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 0 - ] - }, - { - "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", - "expertise": "Intermediate", - "audience": "Research", - "featured": false, - "doNotRecord": false, - "tags": [ - "encryption", - "mempool", - "Censorship Resistance", - "Core Protocol", - "Cryptography" - ], - "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": 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" - ] - }, - "vector": [ 0, 0, 0, 0, - 6, 0, 0, 0, @@ -270858,12 +270666,14 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -270871,10 +270681,42 @@ 0, 0, 0, + 0 + ] + }, + { + "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.", + "track": "Core Protocol", + "type": "Lightning Talk", + "expertise": "Beginner", + "audience": "Stakers/Validators", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [ + "Decentralization", + "Home staking" + ], + "language": "en", + "speakers": [ + "diego-losada" + ], + "eventId": "devcon-7", + "slot_start": 1731643200000, + "slot_end": 1731643800000, + "slot_roomId": "stage-4", + "resources_presentation": "https://docs.google.com/presentation/d/149MDCwjImcWRfdIwZw6lfpbIkNtiT4AFD60ebK9hnNQ" + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -271026,7 +270868,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -271164,6 +271005,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -271494,13 +271336,11 @@ 0, 0, 0, - 6, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -271629,7 +271469,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -271708,6 +271547,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -271723,6 +271563,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -271777,8 +271618,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -272042,12 +271881,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -272059,42 +271896,6 @@ 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", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "ZK", - "Programmable cryptography", - "onchain games" - ], - "tags": [ - "Gaming", - "Mechanism design", - "Mobile" - ], - "language": "en", - "speakers": [ - "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, @@ -272105,13 +271906,6 @@ 0, 0, 0, - 6, - 0, - 0, - 0, - 0, - 0, - 0, 0, 0, 0, @@ -272230,24 +272024,72 @@ 0, 0, 0, + 2, 0, 0, 0, 0, 0, 0, - 6, 0, + 2, 0, 0, 0, 0, 0, 0, + 0 + ] + }, + { + "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", + "expertise": "Intermediate", + "audience": "Research", + "featured": false, + "doNotRecord": false, + "tags": [ + "encryption", + "mempool", + "Censorship Resistance", + "Core Protocol", + "Cryptography" + ], + "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": 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" + ] + }, + "vector": [ 0, 0, 0, 0, + 6, 0, 0, 0, @@ -272537,6 +272379,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -272851,7 +272694,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -272867,7 +272709,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -272955,7 +272796,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -273007,11 +272847,13 @@ 0, 0, 0, + 6, 0, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -273140,6 +272982,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -273287,6 +273130,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -273405,11 +273250,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -273422,32 +273265,6 @@ 0, 0, 0, - 0 - ] - }, - { - "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": "", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [], - "tags": [], - "language": "en", - "speakers": [], - "eventId": "devcon-7", - "slot_start": 1731555000000, - "slot_end": 1731557700000, - "slot_roomId": "decompression-room", - "resources_presentation": "https://docs.google.com/presentation/d/1FvG19MBxNr-yTjRDpb3Z4gWrJzfSxAeauH5sxykoiLg" - }, - "vector": [ 0, 0, 0, @@ -273457,7 +273274,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -273579,10 +273395,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -273594,6 +273412,42 @@ 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", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "ZK", + "Programmable cryptography", + "onchain games" + ], + "tags": [ + "Gaming", + "Mechanism design", + "Mobile" + ], + "language": "en", + "speakers": [ + "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, @@ -273604,6 +273458,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -273734,6 +273589,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -274348,6 +274204,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -274363,6 +274220,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -274450,6 +274308,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -274759,10 +274618,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -274775,47 +274632,10 @@ 0, 0, 0, - 0 - ] - }, - { - "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", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Engineering", - "featured": false, - "doNotRecord": false, - "keywords": [ - "Fuzzing", - "p2p network" - ], - "tags": [ - "network", - "p2p" - ], - "language": "en", - "speakers": [ - "tim-fan", - "sun-haochen", - "fudong-wu" - ], - "eventId": "devcon-7", - "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, - 6, 0, 0, 0, @@ -274938,9 +274758,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -274953,6 +274775,32 @@ 0, 0, 0, + 0 + ] + }, + { + "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": "", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [], + "tags": [], + "language": "en", + "speakers": [], + "eventId": "devcon-7", + "slot_start": 1731555000000, + "slot_end": 1731557700000, + "slot_roomId": "decompression-room", + "resources_presentation": "https://docs.google.com/presentation/d/1FvG19MBxNr-yTjRDpb3Z4gWrJzfSxAeauH5sxykoiLg" + }, + "vector": [ 0, 0, 0, @@ -274962,6 +274810,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -275106,9 +274955,6 @@ 0, 0, 0, - 6, - 6, - 6, 0, 0, 0, @@ -275648,7 +275494,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -275858,7 +275703,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -276121,11 +275965,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -276138,57 +275980,6 @@ 0, 0, 0, - 0 - ] - }, - { - "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", - "type": "Lightning Talk", - "expertise": "Intermediate", - "audience": "Community", - "featured": false, - "doNotRecord": false, - "tags": [ - "Collective Intelligence", - "Security", - "Best Practices", - "user", - "safety", - "Best Practices", - "Collective Intelligence", - "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" - ] - }, - "vector": [ - 6, 0, 0, 0, @@ -276321,8 +276112,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -276335,10 +276128,47 @@ 0, 0, 0, + 0 + ] + }, + { + "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", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Engineering", + "featured": false, + "doNotRecord": false, + "keywords": [ + "Fuzzing", + "p2p network" + ], + "tags": [ + "network", + "p2p" + ], + "language": "en", + "speakers": [ + "tim-fan", + "sun-haochen", + "fudong-wu" + ], + "eventId": "devcon-7", + "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, + 6, 0, 0, 0, @@ -276486,7 +276316,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -276630,6 +276459,9 @@ 0, 0, 0, + 6, + 6, + 6, 0, 0, 0, @@ -276937,7 +276769,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -276968,10 +276799,8 @@ 0, 0, 0, - 2, 0, 0, - 2, 0, 0, 0, @@ -277172,6 +277001,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -277236,8 +277066,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -277383,6 +277211,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -277498,7 +277327,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -277507,7 +277335,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -277515,44 +277342,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, @@ -277560,7 +277349,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -277686,9 +277474,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -277701,6 +277491,57 @@ 0, 0, 0, + 0 + ] + }, + { + "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", + "type": "Lightning Talk", + "expertise": "Intermediate", + "audience": "Community", + "featured": false, + "doNotRecord": false, + "tags": [ + "Collective Intelligence", + "Security", + "Best Practices", + "user", + "safety", + "Best Practices", + "Collective Intelligence", + "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" + ] + }, + "vector": [ + 6, 0, 0, 0, @@ -277852,7 +277693,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -277999,6 +277839,10 @@ 0, 0, 0, + 6, + 0, + 0, + 0, 0, 0, 0, @@ -278302,7 +278146,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -278368,8 +278211,6 @@ 0, 0, 0, - 2, - 2, 0, 0, 0, @@ -278449,6 +278290,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -278479,8 +278321,10 @@ 0, 0, 0, + 2, 0, 0, + 2, 0, 0, 0, @@ -278603,7 +278447,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -278746,6 +278589,22 @@ 0, 0, 0, + 2, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -278863,12 +278722,10 @@ 0, 0, 0, - 2, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -278880,62 +278737,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, @@ -279045,6 +278851,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -279053,6 +278860,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -279060,6 +278868,44 @@ 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, @@ -279067,6 +278913,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -279230,8 +279077,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -279360,6 +279205,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -279679,7 +279525,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -279691,7 +279536,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -279728,7 +279572,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -279812,6 +279655,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -279877,6 +279721,8 @@ 0, 0, 0, + 2, + 2, 0, 0, 0, @@ -279903,7 +279749,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -279961,7 +279806,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -280112,6 +279956,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -280240,62 +280085,15 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 0, - 0, - 0, - 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, @@ -280307,8 +280105,6 @@ 0, 0, 0, - 6, - 0, 0, 0, 0, @@ -280420,10 +280216,12 @@ 0, 0, 0, + 2, 0, 0, 0, 0, + 2, 0, 0, 0, @@ -280435,11 +280233,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, @@ -280598,8 +280447,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -280736,6 +280583,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -281111,7 +280960,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -281141,7 +280989,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -281185,6 +281032,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -281196,6 +281044,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -281232,6 +281081,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -281249,7 +281099,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -281347,7 +281196,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -281408,6 +281256,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -281465,6 +281314,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -281606,7 +281456,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -281615,7 +281464,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -281623,39 +281471,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, @@ -281671,7 +281486,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -281779,9 +281593,11 @@ 0, 0, 0, + 2, 0, 0, 0, + 2, 0, 0, 0, @@ -281794,6 +281610,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, @@ -281805,6 +281660,8 @@ 0, 0, 0, + 6, + 0, 0, 0, 0, @@ -281960,8 +281817,6 @@ 0, 0, 0, - 6, - 6, 0, 0, 0, @@ -282096,6 +281951,19 @@ 0, 0, 0, + 6, + 6, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -282420,7 +282288,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -282627,6 +282494,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -282708,7 +282576,6 @@ 0, 0, 0, - 2, 0, 0, 0, @@ -282735,6 +282602,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -282832,6 +282700,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -282968,14 +282837,12 @@ 0, 0, 0, - 2, 0, 0, 0, 0, 0, 0, - 2, 0, 0, 0, @@ -282983,46 +282850,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, - "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, @@ -283038,7 +282865,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -283133,6 +282959,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -283141,6 +282968,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -283148,6 +282976,39 @@ 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, @@ -283163,6 +283024,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -283327,11 +283189,7 @@ 0, 0, 0, - 6, 0, - 6, - 6, - 6, 0, 0, 0, @@ -283455,6 +283313,8 @@ 0, 0, 0, + 6, + 6, 0, 0, 0, @@ -283913,6 +283773,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -284089,6 +283950,7 @@ 0, 0, 0, + 2, 0, 0, 0, @@ -284199,6 +284061,12 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, 0, 0, 0, @@ -284333,11 +284201,9 @@ 0, 0, 0, - 2, 0, 0, 0, - 2, 0, 0, 0, @@ -284350,49 +284216,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, @@ -284408,7 +284231,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -284499,12 +284321,61 @@ 0, 0, 0, + 2, + 0, + 0, + 0, + 0, + 0, + 0, + 2, + 0, 0, 0, 0, 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": [ + "mario-havel", + "eniko-nagy", + "echo", + "eitan" + ] + }, + "vector": [ 0, 0, 0, @@ -284520,6 +284391,7 @@ 0, 0, 0, + 6, 0, 0, 0, @@ -284702,7 +284574,6 @@ 0, 0, 0, - 6, 0, 0, 0, @@ -284809,7 +284680,11 @@ 0, 0, 0, + 6, 0, + 6, + 6, + 6, 0, 0, 0, @@ -285446,8 +285321,1486 @@ 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, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 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, + 0, + 0, + 0, + 0, + 0, + 0, + 0, + 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, + 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, + 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, + 2, + 2, 0, 0, 0, @@ -285984,9 +287337,9 @@ 0, 0, 0, + 6, 0, 0, - 6, 0, 0, 0, diff --git a/devcon-api/data/vectors/dictionary.json b/devcon-api/data/vectors/dictionary.json index 6a3d0d9f..b060ab46 100644 --- a/devcon-api/data/vectors/dictionary.json +++ b/devcon-api/data/vectors/dictionary.json @@ -126,8 +126,8 @@ "bianca-buzea", "oren-katz", "farhad-asgarov", - "conner-swenberg", "lukas-rosario", + "conner-swenberg", "rob-knight", "veronica-zheng", "forest-fang", @@ -233,9 +233,9 @@ "anna-stone", "damaris-njoroge", "andreas-tsamados", + "julien", "grant-southey", "gregskrileth", - "julien", "thomas-clowes", "mikhail-kalinin", "alex-vlasov", @@ -308,9 +308,9 @@ "oxytocin", "mario-havel", "josh-davis", + "eniko-nagy", "echo", "eitan", - "eniko-nagy", "siddharth-vaderaa", "mark-holt", "philip-daian", diff --git a/devcon-api/src/clients/pretalx.ts b/devcon-api/src/clients/pretalx.ts index 6a3896e3..c5e00c67 100644 --- a/devcon-api/src/clients/pretalx.ts +++ b/devcon-api/src/clients/pretalx.ts @@ -47,7 +47,7 @@ export async function GetSpeakers(params: Partial = {}) { } const speakersData = await exhaustResource(`speakers?questions=all`) - return speakersData.map((i: any) => mapSpeaker(i, params)) + return speakersData.map((i: any) => mapSpeaker(i, params)).filter((s: any) => s.sourceId !== 'ADDJPN') } export async function GetSubmissions(params: Partial = {}) {